There are new articles available, click to refresh the page.
Yesterday — 9 August 2022Vulnerabily Research

Microsoft Patch Tuesday for August 2022 — Snort rules and prominent vulnerabilities

9 August 2022 at 20:44

By Jon Munshaw and Vanja Svajcer.

Microsoft released its monthly security update Tuesday, disclosing more than 120 vulnerabilities across its line of products and software, the most in a single Patch Tuesday in four months.  

This batch of updates also includes a fix for a new vulnerability in the Microsoft Windows Support Diagnostic Tool (MSDT) that’s actively being exploited in the wild, according to Microsoft. MSDT was already the target of the so-called “Follina” zero-day vulnerability in June.  

In all, August’s Patch Tuesday includes 15 critical vulnerabilities and a single low- and moderate-severity issue. The remainder is classified as “important.” 

Two of the important vulnerabilities CVE-2022-35743 and CVE-2022-34713 are remote code execution vulnerabilities in MSDT. However, only CVE-2022-34713 has been exploited in the wild and Microsoft considers it “more likely” to be exploited.

Microsoft Exchange Server contains two critical elevation of privilege vulnerabilities, CVE-2022-21980 and CVE-2022-24477. An attacker could exploit this vulnerability by tricking a target into visiting a malicious, attacker-hosted server or website. In addition to applying the patch released today, potentially affected users should enable Extended Protection on vulnerable versions of the server. 

The Windows Point-to-Point Tunneling Protocol is also vulnerable to three critical vulnerabilities. Two of them, CVE-2022-35744 and CVE-2022-30133, could allow an attacker to execute remote code on an RAS server machine. The other, CVE-2022-35747, could lead to a denial-of-service condition. CVE-2022-35744 has a CVSS severity score of 9.8 out of 10, one of the highest-rated vulnerabilities this month. An attacker could exploit these vulnerabilities by communicating via Port 1723. Affected users can render these issues unexploitable by blocking that port, though it runs the risk of disrupting other legitimate communications. 

Another critical code execution vulnerability, CVE-2022-35804, affects the SMB Client and Server and the way the protocol handles specific requests. An attacker could exploit this on the SMB Client by configuring a malicious SMBv3 server and tricking a user into connecting to it through a phishing link. It could also be exploited in the Server by sending specially crafted packets to the server.  

Microsoft recommended that users block access to Port 445 to protect against the exploitation of CVE-2022-35804. However, only certain versions of Windows 11 are vulnerable to this issue. 

Talos would also like to highlight eight important vulnerabilities that Microsoft considers to be “more likely” to be exploited:  

A complete list of all the vulnerabilities Microsoft disclosed this month is available on its update page

In response to these vulnerability disclosures, Talos is releasing a new Snort rule set that detects attempts to exploit some of them. Please note that additional rules may be released at a future date and current rules are subject to change pending additional information. Cisco Secure Firewall customers should use the latest update to their ruleset by updating their SRU. Open-source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org. 

The rules included in this release that protect against the exploitation of many of these vulnerabilities are 60371 - 60384, 60386 and 60387. There are also Snort 3 rules 300233 - 300239. 

5 Steps to Implement an Application Threat Modeling Program

9 August 2022 at 15:21

It is a given of the current cyber landscape and threat trends that applications and software will get attacked. The question is – how well is your organization prepared to face the attack, what mitigation and remediations strategies are in place, and most importantly – is your company’s culture risk-centric with all the business key players?

The post 5 Steps to Implement an Application Threat Modeling Program appeared first on VerSprite.

The August 2022 Security Update Review

9 August 2022 at 17:31

It’s the second Tuesday of the month, and the last second Tuesday before Black Hat and DEFCON, which means Microsoft and Adobe have released their latest security fixes. Take a break from packing (if you’re headed to hacker summer camp) or your normal activities and join us as we review the details of their latest patches and updates.

Adobe Patches for August 2022

For August, Adobe addressed 25 CVEs in five patches for Adobe Acrobat and Reader, Commerce, Illustrator, FrameMaker, and Adobe Premier Elements. A total of 13 of these bugs were reported through the ZDI program. The update for Acrobat and Reader addresses three Critical-rated and four Important-rated bugs. The critical vulnerabilities could allow code execution if an attacker could convince a user to open a specially crafted file. There are also seven total fixes for Commerce, including four Critical-rated bugs. Two of these could allow code execution and two could lead to a privilege escalation. The XML injection bug fixed by this has the highest CVSS of Adobe’s release at 9.1. The patch for Illustrator contains two Critical and two Important fixes for bugs submitted by ZDI Security Researcher Mat Powell. The most severe could lead to code execution when opening a specially crafted file. Mat is also responsible for the six FrameMaker bugs, five of which could lead to code execution. Finally, there’s a single Critical-rated CVE in the Premier Elements patch resulting from an uncontrolled search path element.

None of the bugs fixed by Adobe this month are listed as publicly known or under active attack at the time of release. Adobe categorizes the majority of these updates as a deployment priority rating of 3, with the Acrobat patch being the lone exception at 2.

Microsoft Patches for August 2022

This month, Microsoft released 121 new patches addressing CVEs in Microsoft Windows and Windows Components; Azure Batch Node Agent, Real Time Operating System, Site Recovery, and Sphere; Microsoft Dynamics; Microsoft Edge (Chromium-based); Exchange Server; Office and Office Components; PPTP, SSTP, and Remote Access Service PPTP; Hyper-V; System Center Operations Manager; Windows Internet Information Services; Print Spooler Components; and Windows Defender Credential Guard. This is in addition to the 17 CVEs patched in Microsoft Edge (Chromium-based) and three patches related to secure boot from CERT/CC. That brings the total number of CVEs to 141. A total of eight of these bugs were reported through the ZDI, including some (but not all) of the bugs reported during the last Pwn2Own.

The volume of fixes released this month is markedly higher than what is normally expected in an August release. It’s almost triple the size of last year’s August release, and it’s the second largest release this year.

Of the 121 new CVEs released today, 17 are rated Critical, 102 are rated Important, one is rated Moderate, and one is rated Low in severity. Two of these bugs are listed as publicly known, and one is listed as under active attack at the time of release. Let’s take a closer look at some of the more interesting updates for this month, starting with the MSDT bug under active attack:

-       CVE-2022-34713 – Microsoft Windows Support Diagnostic Tool (MSDT) Remote Code Execution Vulnerability
This is not the first time an MSDT bug has been exploited in the wild this year. This bug also allows code execution when MSDT is called using the URL protocol from a calling application, typically Microsoft Word. There is an element of social engineering to this as a threat actor would need to convince a user to click a link or open a document. It’s not clear if this vulnerability is the result of a failed patch or something new. Either way, test and deploy this fix quickly.

 -       CVE-2022-35804 – SMB Client and Server Remote Code Execution Vulnerability
The server side of this bug would allow a remote, unauthenticated attacker to execute code with elevated privileges on affected SMB servers. Interestingly, this bug only affects Windows 11, which implies some new functionality introduced this vulnerability. Either way, this could potentially be wormable between affected Windows 11 systems with SMB server enabled. Disabling SMBv3 compression is a workaround for this bug, but applying the update is the best method to remediate the vulnerability.

 -       CVE-2022-21980/24516/24477 – Microsoft Exchange Server Elevation of Privilege Vulnerability
I couldn’t pick between these three Critical-rated Exchange bugs, so I’m listing them all. Rarely are elevation of privilege (EoP) bugs rated Critical, but these certainly qualify. These bugs could allow an authenticated attacker to take over the mailboxes of all Exchange users. They could then read and send emails or download attachments from any mailbox on the Exchange server. Administrators will also need to enable Extended Protection to fully address these vulnerabilities.

 -       CVE-2022-34715 – Windows Network File System Remote Code Execution Vulnerability
This is now the fourth month in a row with an NFS code execution patch, and this CVSS 9.8 bug could be the most severe of the lot. To exploit this, a remote, unauthenticated attacker would need to make a specially crafted call to an affected NFS server. This would provide the threat actor with code execution at elevated privileges. Microsoft lists this as Important severity, but if you’re using NFS, I would treat it as Critical. Definitely test and deploy this fix quickly.

-       CVE-2022-35742 - Microsoft Outlook Denial of Service Vulnerability
This was reported through the ZDI program and is a mighty interesting bug. Sending a crafted email to a victim causes their Outlook application to terminate immediately. Outlook cannot be restarted. Upon restart, it will terminate again once it retrieves and processes the invalid message. It is not necessary for the victim to open the message or to use the Reading pane. The only way to restore functionality is to access the mail account using a different client (i.e., webmail, or administrative tools) and remove the offending email(s) from the mailbox before restarting Outlook.

Here’s the full list of CVEs released by Microsoft for August 2022:

CVE Title Severity CVSS Public Exploited Type
CVE-2022-34713 Microsoft Windows Support Diagnostic Tool (MSDT) Remote Code Execution Vulnerability Important 7.8 Yes Yes RCE
CVE-2022-30134 Microsoft Exchange Information Disclosure Vulnerability Important 7.6 Yes No Info
CVE-2022-30133 Windows Point-to-Point Protocol (PPP) Remote Code Execution Vulnerability Critical 9.8 No No RCE
CVE-2022-35744 Windows Point-to-Point Protocol (PPP) Remote Code Execution Vulnerability Critical 9.8 No No RCE
CVE-2022-34691 Active Directory Domain Services Elevation of Privilege Vulnerability Critical 8.8 No No EoP
CVE-2022-33646 Azure Batch Node Agent Remote Code Execution Vulnerability Critical 7 No No RCE
CVE-2022-21980 Microsoft Exchange Server Elevation of Privilege Vulnerability Critical 8 No No EoP
CVE-2022-24477 Microsoft Exchange Server Elevation of Privilege Vulnerability Critical 8 No No EoP
CVE-2022-24516 Microsoft Exchange Server Elevation of Privilege Vulnerability Critical 8 No No EoP
CVE-2022-35752 RAS Point-to-Point Tunneling Protocol Remote Code Execution Vulnerability Critical 8.1 No No RCE
CVE-2022-35753 RAS Point-to-Point Tunneling Protocol Remote Code Execution Vulnerability Critical 8.1 No No RCE
CVE-2022-35804 SMB Client and Server Remote Code Execution Vulnerability Critical 8.8 No No RCE
CVE-2022-34696 Windows Hyper-V Remote Code Execution Vulnerability Critical 7.8 No No RCE
CVE-2022-34702 Windows Secure Socket Tunneling Protocol (SSTP) Remote Code Execution Vulnerability Critical 8.1 No No RCE
CVE-2022-34714 Windows Secure Socket Tunneling Protocol (SSTP) Remote Code Execution Vulnerability Critical 8.1 No No RCE
CVE-2022-35745 Windows Secure Socket Tunneling Protocol (SSTP) Remote Code Execution Vulnerability Critical 8.1 No No RCE
CVE-2022-35766 Windows Secure Socket Tunneling Protocol (SSTP) Remote Code Execution Vulnerability Critical 8.1 No No RCE
CVE-2022-35767 Windows Secure Socket Tunneling Protocol (SSTP) Remote Code Execution Vulnerability Critical 8.1 No No RCE
CVE-2022-35794 Windows Secure Socket Tunneling Protocol (SSTP) Remote Code Execution Vulnerability Critical 8.1 No No RCE
CVE-2022-34716 .NET Spoofing Vulnerability Important 5.9 No No Spoofing
CVE-2022-34685 Azure RTOS GUIX Studio Information Disclosure Vulnerability Important 7.8 No No Info
CVE-2022-34686 Azure RTOS GUIX Studio Information Disclosure Vulnerability Important 7.8 No No Info
CVE-2022-30175 Azure RTOS GUIX Studio Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-30176 Azure RTOS GUIX Studio Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-34687 Azure RTOS GUIX Studio Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-35773 Azure RTOS GUIX Studio Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-35779 Azure RTOS GUIX Studio Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-35806 Azure RTOS GUIX Studio Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-35776 Azure Site Recovery Denial of Service Vulnerability Important 6.2 No No DoS
CVE-2022-35802 Azure Site Recovery Elevation of Privilege Vulnerability Important 8.1 No No EoP
CVE-2022-35775 Azure Site Recovery Elevation of Privilege Vulnerability Important 6.5 No No EoP
CVE-2022-35780 Azure Site Recovery Elevation of Privilege Vulnerability Important 6.5 No No EoP
CVE-2022-35781 Azure Site Recovery Elevation of Privilege Vulnerability Important 6.5 No No EoP
CVE-2022-35782 Azure Site Recovery Elevation of Privilege Vulnerability Important 6.5 No No EoP
CVE-2022-35784 Azure Site Recovery Elevation of Privilege Vulnerability Important 6.5 No No EoP
CVE-2022-35785 Azure Site Recovery Elevation of Privilege Vulnerability Important 6.5 No No EoP
CVE-2022-35786 Azure Site Recovery Elevation of Privilege Vulnerability Important 6.5 No No EoP
CVE-2022-35788 Azure Site Recovery Elevation of Privilege Vulnerability Important 6.5 No No EoP
CVE-2022-35789 Azure Site Recovery Elevation of Privilege Vulnerability Important 6.5 No No EoP
CVE-2022-35790 Azure Site Recovery Elevation of Privilege Vulnerability Important 6.5 No No EoP
CVE-2022-35791 Azure Site Recovery Elevation of Privilege Vulnerability Important 6.5 No No EoP
CVE-2022-35799 Azure Site Recovery Elevation of Privilege Vulnerability Important 6.5 No No EoP
CVE-2022-35801 Azure Site Recovery Elevation of Privilege Vulnerability Important 6.5 No No EoP
CVE-2022-35807 Azure Site Recovery Elevation of Privilege Vulnerability Important 6.5 No No EoP
CVE-2022-35808 Azure Site Recovery Elevation of Privilege Vulnerability Important 6.5 No No EoP
CVE-2022-35809 Azure Site Recovery Elevation of Privilege Vulnerability Important 6.5 No No EoP
CVE-2022-35810 Azure Site Recovery Elevation of Privilege Vulnerability Important 6.5 No No EoP
CVE-2022-35811 Azure Site Recovery Elevation of Privilege Vulnerability Important 6.5 No No EoP
CVE-2022-35813 Azure Site Recovery Elevation of Privilege Vulnerability Important 6.5 No No EoP
CVE-2022-35814 Azure Site Recovery Elevation of Privilege Vulnerability Important 6.5 No No EoP
CVE-2022-35815 Azure Site Recovery Elevation of Privilege Vulnerability Important 6.5 No No EoP
CVE-2022-35816 Azure Site Recovery Elevation of Privilege Vulnerability Important 6.5 No No EoP
CVE-2022-35817 Azure Site Recovery Elevation of Privilege Vulnerability Important 6.5 No No EoP
CVE-2022-35818 Azure Site Recovery Elevation of Privilege Vulnerability Important 6.5 No No EoP
CVE-2022-35819 Azure Site Recovery Elevation of Privilege Vulnerability Important 6.5 No No EoP
CVE-2022-35774 Azure Site Recovery Elevation of Privilege Vulnerability Important 4.9 No No EoP
CVE-2022-35787 Azure Site Recovery Elevation of Privilege Vulnerability Important 4.9 No No EoP
CVE-2022-35800 Azure Site Recovery Elevation of Privilege Vulnerability Important 4.9 No No EoP
CVE-2022-35783 Azure Site Recovery Elevation of Privilege Vulnerability Important 4.4 No No EoP
CVE-2022-35812 Azure Site Recovery Elevation of Privilege Vulnerability Important 4.4 No No EoP
CVE-2022-35824 Azure Site Recovery Remote Code Execution Vulnerability Important Unknown No No RCE
CVE-2022-35772 Azure Site Recovery Remote Code Execution Vulnerability Important 7.2 No No RCE
CVE-2022-35821 Azure Sphere Information Disclosure Vulnerability Important 4.4 No No Info
CVE-2022-34301 * CERT/CC: CVE-2022-34301 Eurosoft Boot Loader Bypass Important N/A No No SFB
CVE-2022-34302 * CERT/CC: CVE-2022-34302 New Horizon Data Systems Inc Boot Loader Bypass Important N/A No No SFB
CVE-2022-34303 * CERT/CC: CVE-20220-34303 Crypto Pro Boot Loader Bypass Important N/A No No SFB
CVE-2022-35748 HTTP.sys Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2022-35760 Microsoft ATA Port Driver Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-33649 Microsoft Edge (Chromium-based) Security Feature Bypass Vulnerability Important 9.6 No No SFB
CVE-2022-33648 Microsoft Excel Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-33631 Microsoft Excel Security Feature Bypass Vulnerability Important 7.3 No No SFB
CVE-2022-34692 Microsoft Exchange Information Disclosure Vulnerability Important 5.3 No No Info
CVE-2022-21979 Microsoft Exchange Information Disclosure Vulnerability Important 4.8 No No Info
CVE-2022-34717 Microsoft Office Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2022-35742 Microsoft Outlook Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2022-35743 Microsoft Windows Support Diagnostic Tool (MSDT) Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2022-35762 Storage Spaces Direct Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-35763 Storage Spaces Direct Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-35764 Storage Spaces Direct Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-35765 Storage Spaces Direct Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-35792 Storage Spaces Direct Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-33640 System Center Operations Manager: Open Management Infrastructure (OMI) Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-35754 Unified Write Filter Elevation of Privilege Vulnerability Important 6.7 No No EoP
CVE-2022-35777 Visual Studio Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2022-35825 Visual Studio Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2022-35826 Visual Studio Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2022-35827 Visual Studio Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2022-35750 Win32k Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-35820 Windows Bluetooth Driver Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-30144 Windows Bluetooth Service Remote Code Execution Vulnerability Important 7.5 No No RCE
CVE-2022-35757 Windows Cloud Files Mini Filter Driver Elevation of Privilege Vulnerability Important 7.3 No No EoP
CVE-2022-34705 Windows Defender Credential Guard Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-35771 Windows Defender Credential Guard Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-34704 Windows Defender Credential Guard Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2022-34710 Windows Defender Credential Guard Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2022-34712 Windows Defender Credential Guard Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2022-34709 Windows Defender Credential Guard Security Feature Bypass Vulnerability Important 6 No No SFB
CVE-2022-35746 Windows Digital Media Receiver Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-35749 Windows Digital Media Receiver Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-35795 Windows Error Reporting Service Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-34690 Windows Fax Service Elevation of Privilege Vulnerability Important 7.1 No No EoP
CVE-2022-35797 Windows Hello Security Feature Bypass Vulnerability Important 6.1 No No SFB
CVE-2022-35751 Windows Hyper-V Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-35756 Windows Kerberos Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-35761 Windows Kernel Elevation of Privilege Vulnerability Important 8.4 No No EoP
CVE-2022-34707 Windows Kernel Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-35768 Windows Kernel Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-34708 Windows Kernel Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2022-35758 Windows Kernel Memory Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2022-30197 Windows Kernel Security Feature Bypass Important 7.8 No No SFB
CVE-2022-35759 Windows Local Security Authority (LSA) Denial of Service Vulnerability Important 6.5 No No DoS
CVE-2022-34706 Windows Local Security Authority (LSA) Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-34715 Windows Network File System Remote Code Execution Vulnerability Important 9.8 No No RCE
CVE-2022-33670 Windows Partition Management Driver Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-34703 Windows Partition Management Driver Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-35769 Windows Point-to-Point Protocol (PPP) Denial of Service Vulnerability Important 7.5 No No DoS
CVE-2022-35747 Windows Point-to-Point Protocol (PPP) Denial of Service Vulnerability Important 5.9 No No DoS
CVE-2022-35755 Windows Print Spooler Elevation of Privilege Vulnerability Important 7.3 No No EoP
CVE-2022-35793 Windows Print Spooler Elevation of Privilege Vulnerability Important 7.3 No No EoP
CVE-2022-34701 Windows Secure Socket Tunneling Protocol (SSTP) Denial of Service Vulnerability Important 5.3 No No DoS
CVE-2022-30194 Windows WebBrowser Control Remote Code Execution Vulnerability Important 7.5 No No RCE
CVE-2022-34699 Windows Win32k Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2022-33636 Microsoft Edge (Chromium-based) Remote Code Execution Vulnerability Moderate 8.3 No No RCE
CVE-2022-35796 Microsoft Edge (Chromium-based) Elevation of Privilege Vulnerability Low 7.5 No No EoP
CVE-2022-2603 * Chromium: CVE-2022-2603 Use after free in Omnibox High N/A No No RCE
CVE-2022-2604 * Chromium: CVE-2022-2604 Use after free in Safe Browsing High N/A No No RCE
CVE-2022-2605 * Chromium: CVE-2022-2605 Out of bounds read in Dawn High N/A No No RCE
CVE-2022-2606 * Chromium: CVE-2022-2606 Use after free in Managed devices API High N/A No No RCE
CVE-2022-2610 * Chromium: CVE-2022-2610 Insufficient policy enforcement in Background Fetch Medium N/A No No SFB
CVE-2022-2611 * Chromium: CVE-2022-2611 Inappropriate implementation in Fullscreen API Medium N/A No No N/A
CVE-2022-2612 * Chromium: CVE-2022-2612 Side-channel information leakage in Keyboard input Medium N/A No No Info
CVE-2022-2614 * Chromium: CVE-2022-2614 Use after free in Sign-In Flow Medium N/A No No RCE
CVE-2022-2615 * Chromium: CVE-2022-2615 Insufficient policy enforcement in Cookies Medium N/A No No SFB
CVE-2022-2616 * Chromium: CVE-2022-2616 Inappropriate implementation in Extensions API Medium N/A No No N/A
CVE-2022-2617 * Chromium: CVE-2022-2617 Use after free in Extensions API Medium N/A No No RCE
CVE-2022-2618 * Chromium: CVE-2022-2618 Insufficient validation of untrusted input in Internals Medium N/A No No Spoofing
CVE-2022-2619 * Chromium: CVE-2022-2619 Insufficient validation of untrusted input in Settings Medium N/A No No Spoofing
CVE-2022-2621 * Chromium: CVE-2022-2621 Use after free in Extensions Medium N/A No No RCE
CVE-2022-2622 * Chromium: CVE-2022-2622 Insufficient validation of untrusted input in Safe Browsing Medium N/A No No Spoofing
CVE-2022-2623 * Chromium: CVE-2022-2623 Use after free in Offline Medium N/A No No RCE
CVE-2022-2624 * Chromium: CVE-2022-2624 Heap buffer overflow in PDF Medium N/A No No RCE

* Indicates this CVE had previously been assigned by a 3rd-party and is now being incorporated into Microsoft products.

Looking at the remaining Critical-rated fixes, many impact older tunneling protocols. There are fixes for Point-to-Point Protocol (PPP), Secure Socket Tunneling Protocol (SSTP), and RAS Point-to-Point Tunneling Protocol – all of which are correcting remote code execution (RCE) bugs. These are older protocols that should be blocked at your perimeter. However, if you’re still using one of these, it’s probably because you need it, so don’t miss these patches. There’s also a Critical-rated Hyper-V guest-to-host bug being patched this month. The update for Azure Batch won’t be automatic. According to Microsoft, “If you are not running Batch Agent version 1.9.27 or later, you need to resize your pools to zero or recreate your pool.” The final Critical-rated patch this month fixes an EoP in Active Directory. An authenticated attacker could manipulate attributes on computer accounts they own or manage and acquire a certificate from AD CS that would allow elevation to SYSTEM. This bug appears similar to other certificate-based vulnerabilities as Microsoft recommends reviewing KB5014754 for additional steps admins can take to protect their systems.

Moving on to other components, August brings 34 updates just for the Azure Site Recovery component. That makes 66 updates for this component in July and August. This month, there are two RCE bugs, one DoS, and 31 EoP vulnerabilities being fixed. All these bugs involve the VMWare-to-Azure scenario. If you use Azure Site Recovery, you will need to update to 9.50 to be protected. Speaking of Azure, there are eight fixes for RTOS GUIX Studio – six RCEs and two info disclosure bugs. It’s not clear if applications built using RTOS will need to recompile their applications after the patches are applied or not, but it wouldn’t be a bad idea. Rounding out the Azure-related bugs is an info disclosure vulnerability in Azure Sphere that could disclose contents of memory, but root privileges are required to exploit this bug, so it won’t be on anyone’s top 10 list.

There are nine other code execution bugs fixed this month, including another bug in MSDT that is not under active attack (yet). There’s also an intriguing RCE bug in the Bluetooth Service, but Microsoft provides little information on how it would be exploited – just that is limited to network adjacent attackers. There are two Office RCEs and four more in Visual Studio. In these cases, the attacker would need to convince a user to open a specially crafted file. The final RCE bugs are both browser-related. The first is in the WebBrowser Control and the other is in Edge (Chromium-based). While the Edge bug is rated Moderate, the CVSS is listed as 8.3. The lowered severity rating is due to required user interaction, but studies have shown that users click on just about any pop-ups they see.

Looking at the six security feature bypass bugs patched this month, highlighted by a CVSS 9.6 bug in Edge that bypasses a dialog feature that asks users to allow the launching of the Microsoft Store application. There’s a vulnerability in Windows Defender Credential Guard that could bypass Kerberos protection. The SFB bug in Excel bypasses the Packager Object Filters feature. The patch for Windows Hello fixes a vulnerability that bypasses the facial recognition security feature. Finally, the bug in the Windows kernel bypasses ASLR – a vital defense-in-depth measure. It would not surprise me to find this bug incorporated into future exploits, as bypassing ASLR would likely make the exploit more reliable.

Moving on to the remaining EoP bugs fixed in August, the first that jump out are the patches for the Print Spooler. Microsoft lists these as an XI of 1, which means they expect exploitation within 30 days. One of the patches fixes a privilege escalation in System Center Operations Manager: Open Management Infrastructure (OMI). An attacker could abuse it to manipulate the OMI keytab and gain elevated privileges on the machine. For the most part, the remaining privilege escalation bugs require an attacker to already have the ability to execute code on the target. They can then use one of these bugs to escalate to SYSTEM or some other elevated level.

Most months, the information disclosure patches consist primarily of bugs that only result in leaks consisting of unspecified memory contents. There are a couple of those this month, but the others are much more interesting. There are two bugs in the Windows Defender Credential Guard. Both could allow an attacker to access Kerberos-protected data. The remaining info disclosure fixes are for Exchange and could allow an attacker to read target emails. Again, based on changes made to Exchange this month, admins need to enable Extended Protection to fully remediate these vulnerabilities.

Seven different Denial-of-Service (DoS) vulnerabilities receive fixes this month, including the aforementioned Outlook and Azure Site Recovery bugs. Three others impact the older tunneling protocols mentioned above. The LSA component gets a fix for a DoS bug. This is interesting, as LSA is responsible for writing to security logs. It is feasible that attackers could use this bug to try to cover their tracks after an intrusion. There’s also a fix for the HTTP Protocol Stack (http.sys). In this case, an unauthenticated attacker could send specially crafted packets to shut down the service.

The August release is rounded out by a fix for .NET to prevent a blind XXE attack.

No new advisories were released this month. The latest servicing stack updates can be found in the revised ADV990001. The latest updates will be required to install the fixes for the secure boot bugs submitted by CERT/CC.

Looking Ahead

The next Patch Tuesday falls on September 13, and we’ll return with details and patch analysis then. I’ll also be starting a webcast on patch Wednesday to quickly recap the month’s release. You can find it on our YouTube channel. Until then, stay safe, happy patching, and may all your reboots be smooth and clean!

The August 2022 Security Update Review

Security Update Guide Notification System News: Create your profile now

9 August 2022 at 17:20
By: msrc
Sharing information through the Security Update Guide (SUG) is an important part of our ongoing effort to help customers manage security risks and keep systems protected. In January 2022 we introduced Phase One of a new way for customers to receive email notifications about new Microsoft product security content using any email address, not just …

Security Update Guide Notification System News: Create your profile now Read More »

Deploying NodeZero Host

9 August 2022 at 15:22

Product Overview

NodeZero is Horizon3.ai’s flagship Autonomous Pentesting service.  It allows anyone to easily start a pentest, find, fix, and verify hundreds of exploitable vulnerabilities.

Deploying the NodeZero Host

NodeZero utilizes the open source software Docker.  Docker is a container solution which runs applications in siloed environments on a shared host, typically Linux.  A NodeZero admin doesn’t need any Docker knowledge aside from having a host with Docker installed.  

We’ve made it easy to deploy a host that is perfectly suited to run NodeZero.  Below, you’ll find a few options.

Build from Photon ISO

In this example, we’re going to deploy Photon Linux (built by VMWare) using their ISO and then run a script from the console that sets the NodeZero host up.

  • Deploy in your hypervisor of choice.  Use the following settings:
    • 2 CPU’s
    • 8 GB RAM
    • 40 GB HDD
    • Networking should use BRIDGE, NOT NAT.  Set it to use the best network to see traffic.
    • CD-ROM : Attach the .ISO and set it to boot to it.  (NOTE : You’ll likely need to upload the .ISO to your datastore.)

Once the VM is deployed, boot it (verify it boots to the ISO) and run through the installation.  Make sure to set it for either DHCP or Static IP.

Log into the VM using the root password you set during installation, then run the following script.  You’re going to have to type it into the console.
curl https://nodezero.s3.amazonaws.com/build_n0.sh | bash
Once this runs and finishes, you’ll be able to SSH to this VM and paste in the launch script from the Portal.

Build from H3’s ISO

In this example, we’re going to deploy Photon Linux (built by VMWare) using H3’s ISO which will automatically configure the system.

  • Download the H3 NodeZero.iso file.  
  • Deploy in any hypervisor with photon 4.0 support (VirtualBox, VMware, Hyper-V) with the following settings:
    • 2 CPU’s
    • 8 GB RAM
    • 40 GB HDD
    • Networking should use BRIDGE, NOT NAT.  Set it to use the best network to see traffic.
    • CD-ROM : Attach the .ISO and set it to boot to it.  (NOTE : You’ll likely need to upload the .ISO to your datastore.)

Once the VM is deployed, boot it (verify it boots to the ISO) and run through the installation.

If you select DHCP the system will install itself completely and reboot.  Next, login in as root with the initial password of “nodezero”.  Note the VMs IP address, logout and login using an SSH (i.e. PuTTY) connection.  Once logged in via SSH, paste the launch script from the portal.

If static was selected, complete the installation by logging in as root, and typing the following command manually (paste may not function) into the console.

curl https://s3.amazonaws.com/nodezero/build_n0_photon.sh | bash

Once this runs and finishes, you’ll be able to SSH to this VM and paste in the launch script from the Portal.

Deploy H3 pre-built virtual machines

In this example, we’re going to deploy a pre-built virtual machine on an existing hypervisor.  This OVA will be used as the launch point for NodeZero.  Although this Docker host will be used as the base for launching operations executed in the environment, it can be left in place, destroyed, or re-deployed at any time.  Download the appropriate pre-packaged virtual machine (VM) by clicking on link below the platform icon of choice:

Deployment Platform
Virtual Box
Step 1. Download and extract VM
Step 2. Deploy virtual machine

NodeZero virtual machines have been built from a minimal install of Photon 4.0 Linux with the following hardware settings: Linux x86/64, 2 cores, 8gb RAM, 40gb of storage, and a bridge network adapter. 

  • Boot newly deployed VM and login as root (initial password “nodezero”)
  • Take note of displayed IP address and logout
  • SSH (i.e. PuTTY) to IP noted IP address
  • Paste launch script and press enter to start attack

The post Deploying NodeZero Host appeared first on Horizon3.ai.

Downloads Page

8 August 2022 at 18:59

Welcome to the Horizon3.ai downloads page!

The post Downloads Page appeared first on Horizon3.ai.

Host Check Script

8 August 2022 at 18:45

Download the host check script to see if your docker host is ready to run NodeZero.

Alternatively, you can copy/paste this command into your terminal to run immediately:

curl https://downloads.horizon3ai.com/checkenv.sh | bash

NOTE: This does not actually launch a pentest

Troubleshooting / Known Issues

NOEXEC flag on partition

Sometimes users report issues running the health check because they are launching it from within a partition that denies execution. We recommend first cd’ing to $HOME prior to running the health check for good measure:

> cd ~
> curl https://downloads.horizon3ai.com/checkenv.sh | bash

The post Host Check Script appeared first on Horizon3.ai.

Spunk App

9 August 2022 at 15:10

The NodeZero App for Splunk is available on Splunkbase.

The post Spunk App appeared first on Horizon3.ai.

Offensive Security: From OSCE to OSCE3

8 August 2022 at 16:16

OSCE3 (Offensive Security Certified Expert 3) is a certification from Offensive Security which has replaced the (now retired) OSCE certification. This post explores a pentester’s journey from being OSCE certified to becoming OSCE3 certified.

Way back in the halcyon year of 2012, I received the OSCE certification from Offensive Security. At the time, it was regarded as one of the more difficult to obtain certifications and required an in-depth knowledge of several deep technical subjects. These included advanced (at the time) web application hacking, advanced (at the time) shellcoding skills, and advanced (at the time) fuzzing and exploit creation skills.

Upon obtaining the OSCE certification, it was quite easy to show that one had a myriad of skills in the security world and would be able to pentest, or at least be able to hack their way out of a paper bag. However, the security world marches on, and techniques become obsolete or outdated – or in this case, both. What was once considered cutting edge generalist training became a shadow of its former self.

Introducing: Offensive Security Certified Expert 3 (OSCE3)

Fortunately, Offensive Security was aware of this, and recently revamped the OSCE training and certification into far more in-depth and relevant courses. It was split into three separate trainings: Advanced Web Attacks and Exploitation, which has the OSWE certificate, Evasion Techniques and Breaching Defenses, which has the OSEP certificate, and Windows User Mode Exploit Development, which has the OSED certificate. Obtaining all three would give the OSCE3 certificate, which is the new and improved version of the OSCE that I had originally obtained.

I decided that I was going to update my certification status. I was interested both in the advanced training that was offered, and in seeing if all of the security experience I had gained in the meantime made it relevant for me to obtain. Meaning, yeah, I would get some shiny letters, but would it actually up my game? With that in mind, I jumped into the training, eventually receiving all three of the certifications and obtaining my OSCE3, with the final certificate earned 11 months after my first was earned.

What follows is my review of the three courses, with a particular eye towards their relevancy to those who have already been pentesters for a while.

Offensive Security Web Expert (OSWE/WEB-300)

Advanced Web Attacks and Exploitation (referred to as AWAE or WEB-300) is an advanced web attack course that replaces the (admittedly minor) web portion of OSCE. Those who complete the course and pass the exam earn the Offensive Security Web Expert (OSWE) certification. While both courses dealt with reading the source code of a web application and finding a vulnerability, the OSCE version seemed more of an afterthought than a core part of the course. AWAE is designed to change all of that, bringing in a fully fleshed-out course dealing with code review and exploit creation on the web.

And, oh boy, does it ever! There are some basic topics that are taken much further, like XSS and SQL injection. Every tester should know how to exploit them, but the course helps bring more interesting payloads and shift direction on basic exploitation to kick it up a notch. While everyone can drop a BeEF payload and hope it works, or fake a password form for XSS, there is so much more to do, and the content really helps bring that mindset across. Application specific payloads are the norm, and while the exact use cases are not going to be as easily replicated as the studies in the labs, the mindset shift of “Let’s put in the password form in the XSS field” to “What is the most impactful action we can take on the application, and how can I code the payload to do it?” is a fantastic step forward.

And that’s not even the best part. The best part of the AWAE course, where it truly shines? The more niche and unique topics. Deserialization, SSRF, CORS, and more are all explained *thoroughly*. Where perhaps in other courses the explanation was too much, in this one, there is just enough to get all of the nuances across without overloading with useless information.

The proofs of concept are also fantastic. Some of them are contrived, like the CORS payloads, in order to prove the point, but the vast majority of them are works of art explaining how to comprehensively exploit an application. The code created in the course is generally portable and adaptable, so once created, the proof of concept can work for you forever. That’s service.

Of the modules in the material, I think I enjoyed the deserialization the most. Before AWAE, while I could scan and potentially exploit these issues, there were definitely parts I did not understand. However, with the thorough, step by step explanations in the course, every mystery was laid to rest, and it became second nature. In fact, in a live engagement during the course, I was able to pull down an executable from Citrix via a breakout exploit. Upon examining the code, I found an unsafe deserialization in how it handled clipboard data. Several hours of Googling to find a program to edit the hex values and attributes of clipboard data later, I had a simple copy/paste payload that would trigger a shell on the Citrix server. I’ll be honest, before the course, I likely would not have been able to craft that payload, and would have left exploitation as an exercise to the reader.

There are three challenge labs in AWAE, each of which highlights various portions of the course. However, I took the course before the labs were released, so I do not have comments on them. From my activity on the forums and OffSec Discord, I hear good things.

I will hold my comments on the format of the exam, other than to say that of all the OffSec exams, it felt the most real world. At no point did I feel that an obstacle was artificial, and all were overcome the way I would have done it in a live pentest.

There are, of course, some areas where I felt the AWAE course could do with further development. At times it was hard to follow along in the PDF and videos, and making changes to code to add the next step in the PoC scripts can be awkward. Sometimes, that requires moving to the forums or discord to be told that there was a minor error in the code, which can get frustrating at times. Connectivity to the apps can also be an issue, with certain requests hanging because of the VPN or the like. While they exist, they do not lower the quality of the learning.

The real-world value of this course, even for an experienced tester is fantastic. Deeper understanding, better payloads, faster outcomes, and more. This is definitely a course to take to up your game to the next level.

Offensive Security Experienced Penetration Tester (OSEP/PEN-300)

Geared as an advanced infrastructure course, OSEP aims to replace the second leg of the tripod that was OSCE and its materials. The core it seeks to replace was the very spindly leg of creating code-caves and custom XOR encoding schemes.

At its core, OSEP teaches Active Directory fundamentals, antivirus evasion, and lateral movement techniques that are seen everywhere today – and I would say it does an excellent job.

Each module can be characterized by the following path: A technique is discussed, broken down to its individual parts of how and, much more importantly, *WHY* it works, and then implemented. This breakdown is fantastic in all 17 of the modules in the course. At times, the breakdown of the Why is not as important as the How, especially given that, sometimes, a few sentences past a long-winded explanation of Why, we are told to use another tool that does it all for us silently. Even so, walking away with more fundamental knowledge is what allows us to grow as pentesters, and is not something to give away. In the end, each student will have to decide on their own if the Why is as important to them as the How. My advice? It is. Spend time understanding and digesting the Why and doing the extra miles in order to gain the most out of the course.

Certain modules delved into tremendous depth in niche cases that were not necessarily relevant, such as Linux breakouts, or were quick on things that may have benefited from more time on it, such as proxying and domain fronting. While the former could have been better served with a Citrix breakout instead of Linux, in the end it was a fascinating module, and I would not want it changed – perhaps expanded to include RDWeb and Citrix, but certainly not reduced. The domain fronting content is relatively short due to technical limitations and new security measures in the usual domain fronting services, so I understand why it was not so long. But even so, perhaps another, more intense lab would have helped drive home the concepts.

In terms of real-world value, there is no substitution for the OSEP course. Even during studying I was immediately able to put techniques learned into practice, including getting Domain Administrator privileges on two domains that were previously uncracked, using lateral movement techniques, and assisting a colleague with a CLM and AppLocker bypass. Combining the tools with the advanced AV evasion techniques meant that I had a fully homegrown tool that can bypass AV, AMSI, PowerShell CLM, and AppLocker – even on a fully patched and protected modern OS. The satisfaction of watching a command shell with no restriction pop up when a co-worker swears it cannot be done is not to be understated – it’s awesome.

This tool is shown below, which hijacks a thread of notepad and runs a reverse shell (not shown). I take no credit for any of the research – I merely ported some sections of C++ to C# and combined several techniques into one.

The was created to be nothing more than a showcase of various techniques, and is overkill for actual use. If used in the wild, I recommend the following: Don’t. If you must, then choose a single technique and work with that. The tool pictured above works to bypass everything, but is completely unnecessary and not good for any stealth or long-term AV bypass.

Of the course tracks, I’m torn between enjoying lateral movement or AV evasion more. In theory, lateral movement is fun, but limited in practice in the real world, where domains are so often hacked with Responder or Kerberoasting or other “single step to DA” techniques. In practice, AV evasion is a never-ending cat and mouse cycle that consistently allows us to up our game and create better tools. On the whole, I would probably say AV evasion helped up my tooling and coding game the most. See below for a real-world screenshot of me avoiding AV.

In Terminator 2, Robert Patrick improvises the moment when the T-1000 walks through the bars at the jail. The door was supposed to be open but the actor surprised the cast and

The course also has six challenge labs of varying difficulty in order to refine tools and techniques. They are genuinely fantastic and I wish there were more. The challenges each took a few hours to complete, even challenge one, where I went down so many rabbit holes that Alice would be ashamed of me. The general sense was that each challenge took about 4-6 hours, and if there was any point that I was stuck, I had the forums and discord to help me out. Once done, I used the extra time in the labs to refine my tooling, until I had a fully AV+CLM+AMSI+Applocker bypassing version of each shellcode runner (doc, exe, js, vbs, hta, etc), process injection, process hollowing, and other tools that were created in the course of the modules. This came in very handy in exam time when I didn’t need to worry about any protections in place, confident that what I had written would fly invisible and under the radar.

I will withhold my comments about the exam, only saying that it mimics the real world more than the labs, and sometimes the people who create networks make exactly the errors you would think they do.

As far as areas for development with the OSEP course, I would say the main one would be the reliability of labs. Sometime, techniques that worked perfectly a few minutes ago would fail and require a revert. Other times, services would not be available or accessible as necessary, requiring the labs to be reverted 5-6 times. Additionally, some techniques in the course overlook tools that are in every internal infrastructure hacker’s arsenal, in favor of out of date or obsolete versions.

All things considered though, PEN-300 was a fantastic course with immediate returns in my day-to-day pentesting, and I highly recommend it for a more in-depth understand of attack chains and tooling. Do yourself a favor and buy the course.

Offensive Security Exploit Developer (OSED/EXP-301)

The final course in the OSCE3 triad, Windows User Mode Exploit Development (referred to as EXP-301), is the replacement of the main attraction of OSCE. Where the old Cracking the Perimeter (CTP) course shone was in its exploitation and shellcoding portions. EXP-301 takes that and turns it up to 11. It just goes *hard*.

Back in the CTP days, mitigations like ASLR were covered in the course, but in a contrived minor way to show the possibility of a bypass, and DEP wasn’t covered at all. That is not the case anymore. Each of these topics is dealt with in absurd depth. Multiple times. In multiple ways. Once the inner workings of the protections are explained, it’s a very short time before the student is happily crafting leaks and ROP chains. But that’s not all.

but wait, there's more! - But wait There's more

There are two more areas where the course shines – reverse engineering and shellcoding. Let’s take them one by one. Reverse engineering is a complex topic – there are multiple ways to go about it, and the course choses to focus on static reversing with IDA coupled with dynamic with WinDbg. And it works. Complex programs are taken apart in a way that is easily digestible and understood by the student. Students have to go the extra mile with reverse engineering on multiple occasions, but all challenges are doable, if slightly difficult at times. The knowledge of how to work with those two imposing programs is a huge plus of the course, since it takes these two behemoths and demystifies them for common use. Taking apart programs is fun, and really makes me appreciate .NET and DNSpy for my usual day to day.

The shellcoding aspect of the course is likewise a well-done portion. The reverse shell that is created and optimized is perfectly usable in the real world. And the techniques are also easily portable to the real world, as I found to my glee when I needed some quick shellcode to drop in an engagement. Plus, understanding how and why things are done the way they are helps with changing MSF shellcode or others. Inline ASM in C is likewise turned into a cinch, once the knowledge is there.

The course also covers format strings, but since those attacks are more or less disappearing, I won’t spend too much time on them other than to say that using a format string to leak an address is lots of fun.

All of these things, reverse engineering and ALSR bypass and DEP bypass and stack overflows and SEH overflows and shellcode creation and format strings, are practiced on this one program that just has every vulnerability ever. But it does mean that the student has the ability to truly understand and even take it further to find their own vulnerabilities in the exe, so I am counting that as a plus.

The area of the course I enjoyed the most would likely be module 10, where we combined ASLR and DEP bypasses in a single exploit.

The joy of seeing a reverse shell pop after fully reverse engineering and crafting an exploit all by yourself on an extra mile cannot be overstated. I don’t think I have ever felt more like a hacker than when a ROP chain 80 gadgets long that I crafted using sublime text and no debugger, popped me a shell on the first try with no errors.

There are multiple ways to do everything, so an additional challenge to yourself is possible by shifting the bypass method from the one outlined in the course to one of your own choosing, and is a great way to practice.

There are three challenges in the course. They all touch on various aspects of the course, but do not really overlap much. I personally only did challenges one and two, not getting a full shell with challenge three before I passed the exam. However, challenges one and two were loads of fun. I do believe they are necessary, and I definitely think that all of the extra miles in this course are needed to be able to pass the exam.

I won’t say much about the exam, however I will say that it was a significantly difficult endeavor. Do not get discouraged by the goals, as there are many ways to do things. Also, my solutions were not the intended solutions and saved me a huge amount of effort, so there are different ways to do things.

However, there are some fairly glaring omissions from the course – x86 is not going to be the average user’s architecture, and creating exploits for it seems like a tee-ball league version of hacking versus true major league hacking. Also, so much of the course feels like a blueprint was given for the concepts, and then we are pushed into the deep end. The exam certainly felt like that, but it *is* the exam, so it’s understandable. In terms of real-world value, this is hard to say. The course is fantastic, but x86 is not really used any more – so for practical exploitation, use this course as a jumping point to x64. However, if your aim is to understand concepts and put them to use in other areas of the hacking world, this is a fantastic jump point into these kinds of topics. All in all, I would say the course is worth taking.


After having taken all three of the replacement courses, I came to the conclusion that upgrading the certificate was definitely a great idea. I learned a huge amount in each area and put it to use almost immediately in all cases. I would encourage even experienced testers to go ahead and grab the training.

I would say that for OffSec, there are effectively two things here, the training and the certificate. Even if you should choose not to take the exam, the course itself is extremely high value and you won’t walk away feeling like you are missing out. If it’s not an option to take all three courses, then choose the one most relevant to your day-to-day testing and get on it. They are all excellent, and worth the effort of Trying Harder.

Also, the challenge coin for OSCE3 is pretty sweet, so that’s a fun goal to go for. In the end, I feel like taking the courses made me a better pentester in all of the areas covered.

The post Offensive Security: From OSCE to OSCE3 appeared first on Nettitude Labs.

Before yesterdayVulnerabily Research

Implementing the Castryck-Decru SIDH Key Recovery Attack in SageMath

8 August 2022 at 21:44


Last weekend (July 30th) a truly incredible piece of mathematical/cryptanalysis research was put onto eprint. Wouter Castryck and Thomas Decru of KU Leuven published a paper “An efficient key recovery attack on SIDH (preliminary version)” describing a new attack on the Supersingular Isogeny Diffie-Hellman (SIDH) protocol together with a corresponding proof-of-concept implementation.

SIDH is at the core of the Post-Quantum key encapsulation mechanism SIKE, which was expected to continue to round four of the NIST Post-Quantum Project for consideration of standardisation. The paper says that their proof of concept code can break the proposed NIST level 1 parameters (supposedly approximating security on-par with AES-128) in an hour of single core computation, and the strongest parameter set in less than 24 hours.

However, the proof of concept code published has been written using the computer algebra software system Magma. Magma is a very efficient and powerful piece of software, but it is difficult for people to obtain access to. This meant that despite being able to run the attack over a lunch break, most of the community was unable to verify the result at all.

Motivated by a beautiful attack and a love of open-source software, a plan was made to read the attack and implementation and then reimplement it in SageMath; a free, open-source mathematics software system. This was not only a great opportunity to learn exactly how the attack came together, but the effort should also then open up the research to the cryptographic community, who could verify the attack themselves. There’s nothing more convincing than seeing the secret key appear before your very eyes!

This blog post is about the attack, but it’s mainly a story about how the code was reimplemented and the help which was received from collaborators along the way. It’s been a wild week and there’s a lot to learn in more detail, but for those eager to break some isogeny based crypto protocols, the implementation is now available on a public GitHub repository. Thanks to some additional performance enhancements that we’ll talk about along the way, you can break the SIKE NIST level 1 parameter set with your laptop, a fresh download of SageMath and only 10 minutes of your time.

Approximate Running Time $IKEp217 SIKEp434 SIKEp503 SIKEp610 SIKEp751
Paper Implementation (Magma) 6 minutes 62 minutes 2h19m 8h15m 20h37m
Our implementation (SageMath) 2 minutes 10 minutes 15 minutes 25 minutes 1-2 hours
Comparison between running times of the original proof of concept released with Wouter Castryck and Thomas Decru‘s paper, and the current version of our SageMath implementation. Our implementation is available in a public repository: https://github.com/jack4818/Castryck-Decru-SageMath

Table of Contents

The search for quantum-safe cryptography

To understand the importance of the attack, it helps to put it in context. In 2016, NIST announced the Post-Quantum Cryptography Project. The aim was to call on cryptographers to submit algorithms split between two categories: key encapsulation mechanisms (KEMs) and digital signatures. The motivation is that the asymmetric cryptography currently in place — Diffie-Hellman key exchanges using elliptic curves for a KEM and ECDSA/EdDSA for digital signatures — can be efficiently broken by an attacker with access to a sophisticated quantum computer using Shor’s algorithm.

Although the construction of such a quantum computer has not been achieved, history tells us that the uptake of new algorithms is slow (we still see 3DES and MD5 in the wild, for example). So NIST believe the best plan is to act preemptively and to start working on getting new, quantum-safe algorithms out there as soon as possible.

Constructing new cryptographic algorithms is complicated. Furthermore, for asymmetric algorithms, we rely on the existence of some trapdoor function which is easy to perform one way and hard to undo the other. Typically, mathematics is used to create these functions (multiplication/factoring for RSA or exponentiation/discrete logarithms for elliptic curves). These mathematical trapdoors always come with some associated structure. The hope is that we understand the structure enough that we can confidently assume certain problems are hard to solve. In a quantum setting, it is the Abelian group structure of the ring of integers modulo N and the group of points on an elliptic curve which results in the break of RSA and ECC.

The balancing act of structure and cryptographically hard problems is at the heart of why projects such as the NIST PQCrypto Project take so long, with multiple rounds and iterative algorithm design. Cryptographic protocols can be designed and studied for years only to break after one very clever idea. This happened recently when Ward Beullens published Breaking Rainbow Takes a Weekend on a Laptop in June 2022, effectively knocking Rainbow out of the PQC project.

Last month, NIST recently announced the end of round three of the project and with it, their first selection of algorithms to be standardised for cryptographic applications:

  • CRYSTALS-Kyber (KEM).
  • CRYSTALS-Dilithium, Falcon, and SPHINCS+ (Digital signatures).

To ensure diversity of trapdoor functions, NIST are starting round four. The hope is to find new KEM algorithms which have different hardness assumptions to Kyber, increasing the chances of having a long-lasting, quantum-safe KEM. A recent blog post by Thomas Pornin discusses in more detail the round three selections and a history of the NIST PQC project.

SIKE: Supersingular Isogeny Key Exchange

One of the candidates selected for round four is SIKE (Supersingular Isogeny Key Encapsulation), an isogeny based KEM which uses SIDH to perform the key exchange. This blog post won’t be a precise discussion of isogeny based cryptography, but for those who are interested here are some links to click through for a great first introduction:

To give some intuition though, we give an inaccurate but morally correct overview of what’s happening by first making a stop past something more familiar.

In an elliptic curve key exchange, a shared secret is found in the following way. Alice and Bob both start with a fixed point and using a secret number they “move” from this point to their new points A and B, which are made public. They send these to each other and then Alice (Bob) moves from B (A) as they did before, using the same secret number on the new point. By doing this, they end up at the same “place”, a point S, and this is used to derive a key for the rest of their communication.

In SIDH a very similar thing happens. Alice and Bob both start from the same place, but now instead of the start being a point on a curve, it is an elliptic curve itself. For reasons that aren’t necessary when so many other details are missing, not any old curve will do here. A special type of curve is used, which mathematicians know as a supersingular elliptic curve.

Alice and Bob then “move” from a public starting curve to some new curve, which will be part of the public data. This “movement” between curves is performed by creating a secret isogeny, which is a clever map which takes Alice from one curve to some other supersingular curve (while also preserving the group structure of the curve). The isogeny can be generated efficiently because of the clever parameters SIDH uses and for this post, it’s enough to know that Alice creates her secret isogeny by generating a secret integer. This is mixed into some fixed elliptic curve points which are defined by the SIKE parameters. This resulting secret point is what is used to generate the secret isogeny. The takeaway is: if an attacker can recover this secret integer, the whole protocol is broken.

To perform a key exchange, Alice and Bob both generate random numbers and use these to create secret isogenies. They use these to move to some new curves E_A and E_{B} and they share these curves with each other. The Isogeny path problem is that given two elliptic curves, it is generally very hard to determine the isogeny which links them. If you want a visual picture, the isogenies linking supersingular curves make a very messy graph and it’s easy to get lost. This is similar in feeling to how given two points in an elliptic curve key exchange, the discrete log problem is that it’s assumed to be hard to recover the integer which relates them.

In SIDH things aren’t quite as simple as the elliptic curve example. Given each other’s public curves, if Alice and Bob both naively use their isogenies again to try and move to the same place, they do not end up on a shared curve. All is not lost though, SIDH fixes this by including additional information in the exchange. Not only does Alice (Bob) send Bob (Alice) their public curve, they also use their isogeny and use it to map a pair of public points from the starting curve to their new curve. These extra points are known as the torsion, or auxiliary points. Sending a package of the mapped curve with the pair of mapped points is enough to ensure Alice and Bob end up on a shared secret curve (technically, up to isomorphism, but if this doesn’t make sense, forget you read it) and this can be used to derive keys.

SIKE builds on the SIDH protocol with fixed parameters and key encapsulation. But for our purposes for this attack, breaking SIDH also breaks all parameter sets of SIKE.

Since SIDH has been proposed, the inclusion of additional information by sending the image of the torsion points has worried researchers. The concern was that the isogeny path finding problem could remain hard while the potentially easier problem, known as the Supersingular Decision Diffie-Hellman problem, could be broken through some information leaked out by how the secret isogeny acts on these auxillary points.

This is the problem which Wouter Castryck and Thomas Decru have shown is easy! It turns out, the structure which is currently used in SIDH to make a sensible key-exchange mechanism leaked too much information about secret values. Through some genius mathematics and a deep understanding of the protocol, the Castryck-Decru attack recovers Bob’s secret isogeny in polynomial time.

This blog post is a celebration of this attack, and to talk about it, we talk about its implementation. The proof-of-concept code that Castryck and Decru shared with their paper was written to run in a special computer algebra software package called Magma. So, what’s Magma?

Computer algebra software

Cryptographic attacks which rely on advanced mathematics are often written using specialised mathematical software. For cases when the code needs to be hyper-optimised, the code is then usually translated to a more performant language after a proof of concept is developed. However, more often than not, these pieces of software are advanced enough to do what the researchers need. Let’s review two of the most commonly used software systems.

  • Magma is a computer algebra software package maintained by the University of Sydney. It is known for having expansive coverage, with efficient implementations of computational algorithms from algebra, number theory and algebraic geometry. It is also closed source, expensive and only available to people associated with institutions who maintain licence distribution.
  • SageMath is a free, open-source mathematics software system licensed under the GPL. Its mission is to “Create a viable free open source alternative to Magma, Maple, Mathematica and Matlab.” SageMath is built on top of Python, but many algorithms come from other open-source packages and are accessed through wrappers and interfaces, allowing high performance computation.

Because of the barriers to getting hold of Magma, many people active in the cryptographic research community don’t have access. However, if you are interested and want to run snippets of code, the Magma calculator allows cloud based computations (albeit with a two-minute run time limit).

In contrast, everyone with a computer has access to SageMath. Personally, I have used it extensively to learn about cryptography, build and deliver cryptography challenges for CryptoHack, and even occasionally to implement maths papers for fun! It’s an incredible piece of software.

Overview of the attack

Another disclaimer before starting this section, this blog post does not aim to give a comprehensive discussion of how Castryck and Decru have broken SIDH. The mathematics is very advanced, and requires a deep understanding of how SIDH works, as well as the more esoteric research of Abelian surfaces and Richelot isogenies.

The hope is only to give enough context that the rest of the post is motivated and enjoyable to read. So before starting, here are some great resources from the community discussing the result which the interested reader can browse through:

Attacking the structure of SIDH

Note: if you’re happy just accepting there’s a clever mathematics which makes this attack work, you can skip the next two sections!

To allow the attack to be successful, the attack uses several properties of the SIDH protocol and SIKE parameters. Whether all of these conditions are necessary for the attack to work are part of ongoing research, but to set the scene, let’s look at what is used.

The public key contains the image of the torsion points

  • This is totally vital for the attack. They are also totally vital for SIDH to be a sensible key exchange protocol, so in its current form, SIDH cannot avoid this part of the attack.
  • Knowing how the secret isogeny acts on the torsion points has been worrying for a long time. In Improved torsion-point attacks on SIDH variants, the authors of the paper heavily reduced the parameter space for SIDH, but the attack did not extend to the SIKE parameters.
  • In section 8.1 of the paper, arbitrary torsion points are discussed. It is thought that changing the form of the prime (and hence changing the torsion points) should inherently change nothing about the attack.

The secret isogenies have a fixed degree

  • Alice computes an isogeny of degree 2^a and Bob computes an isogeny of degree 3^b. This is the core of how the algorithm works, but it is also core to how the attack works.

The above two properties are the most important and are also special to SIDH. For this reason, people believe the attack cannot be generalised to other isogeny based schemes such as CSIDH or SQISign, which do not have isogenies of a fixed degree or additional torsion points.

The starting curve has a known endomorphism ring

  • Generating supersingular curves randomly is hard. Of the p^2 possible elliptic curves, only (about) \lfloor p/12 \rfloor are supersingular. For cryptographically large p, finding a supersingular curve by guessing is not reasonable.
  • Luckily, we have a way to write down a special supersingular curve for a given prime (which comes from the theory of complex multiplication). However, this method also gives us more structure: we learn the endomorphism ring of the curve.
  • One could use one of these curves, then generate an isogeny to walk to some random curve. However, knowing the starting curve and the isogeny used to get the new curve also leaks the endomorpishm ring of the new curve.
  • In sections 8.2 and 8.3, Castryck and Decru outline that the attack should weaken the security of SIKE parameters, even when the endomorphism ring of the starting curve unknown.

The Glue-and-Split oracle

From a high level, Castryck and Decru’s attack recovers the secret integer (in base 3) which is used to generate the secret isogeny; it does not directly compute the secret isogeny itself. The algorithm works by taking a step along the unknown path and asking the oracle if the step was correct. Depending on the return value, a new step can be guessed, or it can continue down the path to discover the next secret digit.

Walking down Bob’s secret path, there are only one of three directions to take after each step. This means for each step that is taken, at most two calls to the oracle are needed. This is what makes the attack so efficient. Every step (except for the first few, depending on the parameter choices) can be validated one by one and the secret integer is recovered digit-by-digit.

The genius of the attack was finding a method to validate whether the step taken is on the right path. As the constructed oracle only requires public data, the SIDH protocol as currently implemented is totally broken. Due to the efficiency of the attack, the common defense of increasing the bit-size of the parameter space is not suitable.

The oracle begins with the collected public data. A cleverly constructed isogeny allows the creation of a new curve C from the starting curve E_{start}. Very loosely, the oracle takes these two curves and makes a new object from their product, which can be seen as a higher-dimension abelian surface. The Glue-and-Split oracle then takes pairs of points from E_{start}: (P,Q) and C: (P_C, Q_C) and represents them as points on this higher-dimensional object (P_C, P) and (Q_C,Q) (these are points on the Jacobian of a hyperelliptic curve).

This hyperelliptic curve and pair of new points are mapped through a chain of isogenies (known as Richelot isogenies). At the end of this chain, if the hyperelliptic curve can be decomposed back into a product of elliptic curves, then the correct digit must have been guessed. The reason this all works is because of a theorem by Kani (1997) and the ability to construct the auxiliary isogeny from E to C (which in the current implementation abuses the known endomorpishm ring of the curve).

Implementing the attack

The following discussion is a fairly informal write-up of the 24-hour period starting from an empty repository and ending with a efficient implementation of the attack. The hope is that this not only helps to give a good review of the pieces that come together for the attack to work, but also gives an impression of the problems which arise when implementing mathematical algorithms (and other issues introduced by rushing fingers a little too excited to type precisely).

Learning Magma: or how I came to love syntax bugs

The first step of converting Magma to SageMath was understanding how to translate the syntax. Some changes, like variable declaration with a := 1; rather than a = 1 were simple to fix up.

Additionally, many of the higher-level mathematical objects such as EllipticCurve() orPolynomialRing() had almost identical representations. For anything I didn’t recognise, it was usually enough to find the function in the Magma Documentation, read the expected behaviour and find the relevant function in the SageMath Documentation. In some cases Magma had support for structures which SageMath didn’t perfectly mirror.

One example of this was that Magma can work with multivariate function fields:

// magma
Uff<u0, u1, v0, v1> := FunctionField(Fp2, 4);

However, when trying to define this in SageMath, it was found that only univariate function fields could be constructed directly. The workaround for this was found in the community support forum where it was explained that you could create a suitable object by first defining a multivariate polynomial ring and then creating the fraction field from it:

# SageMath
Uff_poly.<u0, u1, v0, v1> = PolynomialRing(Fp2, 4)
Uff = Uff_poly.fraction_field()

Mathematics aside, the difference which caused the most bugs during conversion was very simple. Magma accesses elements in arrays using 1-index, and when looping through a range, it is inclusive of the upper bound. In contrast, SageMath is 0-indexed and does not include the upper bound. In this sense, Magma behaves in the “old-style” similar to Fortran or Pascal, where as (via Python) SageMath follows the 0-index convention started with C (or rather its predecessor B).

As an example: printing out integers from an array in both languages would be achieved as:

// Magma 
my_array := [2,3,5,7,11];

for i in [1..5] do
 print my_array[i];
end for;
// output: 2,3,5,7,11
# SageMath
my_array = [2,3,5,7,11]

for i in range(0,5):
# output: 2,3,5,7,11

This meant that careless copy-pasting and tidying could easily introduce off-by-one errors throughout the code. This is exactly what happened and correcting these syntax typos was being done all the way up to the code working!

Getting organised

The first goal was to reimplement the SIKE_challenge.m file, which was an implementation of the attack which was said to have solved Microsoft’s $IKEp217 challenge (this was announced last year, with a cash bounty of $50,000 for the first team to crack it). The prime used has only half the bits of the NIST level 1 parameters (SIKEp434) and supposedly ran in approximately 5 minutes using the Magma script (too long for the free Magma calculator, sadly…). As such, it was the perfect place to start.

The work to reimplement the attack was split between fairly easy but busy work translating SIKE_challenge.m into valid SageMath and more careful and mathematical work reimplementing the functions in the helper file richelot_aux.m. If this attack worked it would then be a case of changing a handful of lines for the attack on SIKEp434, which was said to take about one hour to complete when running the Magma files.

Opening up richelot_aux.m, the first thing to do was to read through the functions and get an idea of the work ahead:

  • Does22ChainSplit()
    • The main oracle, which given the necessary curves and points returns True when the correct digit is guessed.
    • First thought: not too hard.
  • FromProdToJac() and FromJacToJac()
    • Helper functions for Does22ChainSplit() which takes us from points on an elliptic curve to points on the Jacobian of a hyperelliptic curve and then performs the Richelot isogenies.
    • First thought: very long with a couple scary lines which SageMath might have trouble with
  • Pushing3Chain()
    • Compute a chain of isogenies given a curve, quotienting out point of order 3^i .
    • First thought: easy. Very similar to code I’ve written before.
    • In fact thanks to a recent update to SageMath by Lorenz Panny, this could probably be swapped out for E.isogeny(K, algorithm="factored"). However, to align the code with the PoC, it was decided to reimplement the function as it appeared in the Magma code.
  • Pushing9Chain() and OddCyclicSumOfSquares()
    • Obsolete code, which could be simply ignored. OddCyclicSumOfSquares() is almost certainly the code which was used to precompute the values u,v in uvtable.m. As there’s no need to recompute this array, the function is not needed.

As the function is short, here’s the Magma, then SageMath version of Pushing3Chain(). This is a fair representation of how similar code written in Magma and SageMath is:

// Magma
function Pushing3Chain(E, P, i)
 // compute chain of isogenies quotienting out a point P of order 3^i
 Fp2 := BaseField(E);
 R<x> := PolynomialRing(Fp2);
 chain := [];
 C := E;
 remainingker := P;
 for j in [1..i] do
   kerpol := x - (3^(i-j)*remainingker)[1];
   C, comp := IsogenyFromKernel(C, kerpol);
   remainingker := comp(remainingker);
   chain cat:=[comp];
 end for;
 return C, chain;
end function;
# SageMath
def Pushing3Chain(E, P, i):
   # Compute chain of isogenies quotienting out a point P of order 3^i
   Fp2 = E.base()
   R.<x> = PolynomialRing(Fp2)
   chain = []
   C = E
   remainingker = P
   for j in range(1, i+1):
       kerpol = x - (3^(i-j)*remainingker)[0]
       comp = EllipticCurveIsogeny(C, kerpol)
       C = comp.codomain()
       remainingker = comp(remainingker)
   return C, chain

Aside from worrying about the helper functions, Does22ChainSplit() was just as simple to reimplement. SIKE_challenge.m itself was about 300 lines of syntax changes (switching out loops, populating arrays with integers). There was a bit of work composing some isogenies, computing Weil pairings and doing some elliptic curve arithmetic, but thanks to previous experience in writing similar code, the conversion went fairly smoothly.

Two functions to go, this was going to be done by lunch!

Warning: falling back to very slow toy implementation

The first major difficulty came while reimplementing FromProdToJac(). At a high level, this function takes points P,Q on an elliptic curve E and points P_C , Q_C on the elliptic curve C and computes the image of the points (P_C, P) and (Q_C, Q) on the Jacobian of a hyperelliptic curve. Hmm ok maybe that’s not such a high level.

Brushing aside what it does, let’s talk about how it tries to do this.

First, five multivariate equations in four variables are defined. Although the lines which do this look dense, the similarity between Magma and SageMath meant not much work was needed at all. The goal is to find a solution to all five equations, which can then be used to construct the necessary points on the Jacobian of the target hyperelliptic curve. Details of this process are is described in section 6.1 of the paper.

The standard method to solve systems of equations like this is to first build a Gröbner basis from the equations. Magma comes with GrobnerBasis() and it is very efficient and works with a wide range of polynomial rings. The following code snippet doesn’t obviously use GrobnerBasis(), instead a scheme is created from an affine space and the set of equations. Calling Points(V) on the scheme finds the set of points, which are equivalently the set of solutions to the polynomials! Points(V) does this by (in part) calling GrobnerBasis() under the hood.

A4<U0, U1, V0, V1> := AffineSpace(Fp2, 4);
V := Scheme(A4, [eq1, eq2, eq3, eq4, eq5]);

// point with zero coordinates probably correspond to "extra" solutions,
// we should be left with 4 sols (code may fail over small fields)

realsols := [];
for D in Points(V) do
   Dseq := Eltseq(D);
   if not 0 in Dseq then
       realsols cat:= [Dseq];
   end if;
end for;

Rewriting this in SageMath, we get something that looks very similar

A4.<U0, U1, V0, V1> = AffineSpace(Fp2, 4)
V = A4.subscheme([eq1, eq2, eq3, eq4, eq5])

# point with zero coordinates probably correspond to "extra" solutions,
# we should be left with 4 sols (code may fail over small fields)

realsols = []
for D in V.rational_points():
   Dseq = list(D)
   if not 0 in Dseq:

Again, like Magma, this calls grobner_basis() under the hood to find the set of points. However, running this code, we get the following message from SageMath:

verbose 0 (3848: multi_polynomial_ideal.py, groebner_basis) Warning: falling back to very slow toy implementation.

Uh oh… Just how slow is very slow? When running the attack, FromProdToJac()would be called for each oracle request. This meant it would be called a few hundred times for the easiest $IKEp217 challenge and a magnitude more for the hardest parameter set.

To see how slow very slow was, the code was left running while some fresh coffee was brewed and coming back to the terminal, a second warning was now showing:

verbose 0 (3848: multi_polynomial_ideal.py, groebner_basis) Warning: falling back to very slow toy implementation.
verbose 0 (1081: multi_polynomial_ideal.py, dimension) Warning: falling back to very slow toy implementation.

Okay, so technically this is progress, but considering the Magma file was totally finished within five minutes, we would need a smarter way to solve this problem if there was any hope to have this script recover the secret key.

When in doubt, make things easier

The usual method when solving problems like this using SageMath is to go crawling through the documentation. This wasn’t the first time a problem like this had come up while implementing algorithms and so the hope was some new ideas would start jumping out if enough documentation was read through.

Years of research experience quickly suggested that the first thing to do was to simply reduce the complexity of the problem. The file SIKE_challenge.sage was rewritten as the new baby_SIDH.sage, which shared a very similar structure, but now with a much smaller, 64-bit prime. The hope was to find something which worked reasonably on this smaller problem then worry later about making it more efficient after it was confirmed that the attack worked.

To create baby SIDH SIKEp64, first a prime was found such that p \equiv 3 \pmod 4 and p = 2^a 3^b - 1:

# Baby SIKEp64 parameters
a = 33
b = 19
p = 2^a*3^b - 1

Then reusing some old code from other isogeny projects, fresh public torsion points were generated as well:

def get_l_torsion_basis(E, l):
   n = (p+1) // l
   return (n*G for G in E.gens())

P2, Q2 = get_l_torsion_basis(E_start, 2^a)
P3, Q3 = get_l_torsion_basis(E_start, 3^b)

# Make sure Torsion points are
# generated correctly
assert 2^(a-1)*P2 != infty
assert 3^(b-1)*P3 != infty
assert P2.weil_pairing(Q2, 2^a)^(2^(a-1)) != 1
assert P3.weil_pairing(Q3, 3^b)^(3^(b-1)) != 1

Using the baby parameters with a SIDH key generation, the public data could be pushed back into the attack and…

verbose 0 (3848: multi_polynomial_ideal.py, groebner_basis) Warning: falling back to very slow toy implementation.
verbose 0 (1081: multi_polynomial_ideal.py, dimension) Warning: falling back to very slow toy implementation.

After letting this run for about 30 minutes the program was exited. It was obvious that this method was the wrong avenue for the SageMath implementation. Back to the drawing board.

The things you can do with friends by your SIDH

While fishing around more and more specific searches such as “sagemath fast groebner basis multivariate polynomial ring” (this is the page that seems like the solution should be in, but nothing ever quite worked) I additionally asked my CryptoHack friends for advice and made a tweet explaining the problem.

SageMath is used by a lot of people in the crypto community, and often people find clever tricks when solving puzzles and CTF challenges which come in handy in times like this. The hope was that someone had solved a similar problem before and could point toward the correct way to construct the solution.

Pretty quickly after reaching out to people, some really cool suggestions were offered. The power of the internet!

  • Lorenz Panny suggested to Weil restrict the equations by introducing an extra variable and move from working in F_{p^2} to F_p
    • This meant the toy implementation of Gröbner was not needed anymore as the polynomial ring would be defined over a simpler field, but now the system of equations was so complicated, the code was still too slow
  • Tony Shaska suggested that instead of computing the Gröbner bases, a faster method could be to instead use resultants to remove variables from the equation one at a time and then solve the equation in a univariate polynomial ring and work backwards.
    • This is a clever idea but SageMath was still too inefficient. The only method I had to compute resultants for the polynomial ring was using the determinant of the Sylvester matrix and this is very slow.
  • Bryan Gillespie suggested to try and use the Macaulay2 interface to compute the Gröbner basis. This doesn’t come with SageMath by default, but is free and open-source and can be included pretty easily. It’s also known for being pretty fast
    • This might work, but the current SageMath interface doesn’t allow for sending extension fields to Macaulay2 (it’s not even certain from the documentation that Macaulay2 can do this, but the SageMath interface certainly can’t). For this to have a chance at working, one would first have to re-write the interface.

The solution came from Rémy Oudompheng, who saw a way to avoid the problem altogether:

Are you trying to lift a pair (P, Pc) to the Jacobian? I wonder if it’s easier to lift (P, 0) to a divisor on H, lift (0, Pc) to a divisor and add them? I may be confused but it feels like it gives the answer without solving any equation

Original Tweet

Rémy joined me in the CryptoHack discord and we started chatting more about how this could solve the problem. His novel solution to the lifting described in section 6.1 seemed to be working, and what’s more, the same ideas would carry over to the JacToJac() function. Only days after the initial attack, it was wonderful seeing new perspectives on how to efficiently solve the problem.

This is a beautiful result and I’m really happy to have had the time working with Rémy on this. I never would have had the above insight to dodge the slow toy implementation and it gave me an opportunity to learn more about hyperelliptic curves.

Piecing it all together

While Rémy worked on his novel implementation for FromProdToJac() and FromJacToJac(), the remaining work was to go through the rest of the Magma code and convert it to valid SageMath. With these last two functions finished and the rest of the attack all scripted, it was time to see whether the algorithm could recover Bob’s private key given only public data generated from the baby SIDH parameters.

Before the gratification of a successful run, as is usual with late night coding, some additional off by one errors were introduced and then removed while Rémy pushed the new hyperelliptic lifting and Richelot isogeny code. We both ran our script, which failed dramatically in the last few lines when constructing the private key thanks to more syntax errors:

key = sum(skB[i]*3^(i-1) for i in range(1..b-2))
TypeError: 'generator' object cannot be interpreted as an integer

Off by one and a remaining .. in the range!! Fixing this to what should have been written all along:

# Magma
# key := &+[skB[i]*3^(i-1) : i in [1..b-3]];
# SageMath
key = sum(skB[i]*3^i for i in range(b-3))

the following output appeared in the terminal:

Bridging last gap took: 0.1307520866394043
Bob's secret key revealed as: 15002860
In ternary, this is: [1, 1, 1, 1, 0, 0, 0, 2, 0, 0, 2, 0, 1, 0, 0, 1]
Altogether this took 43.73990249633789 seconds.

It worked!! The attack successfully recovered Bob’s private key in less than a minute, all thanks to some brilliant mathematics. It was so exciting to see Wouter Castryck and Thomas Decru’s attack run in real time on a laptop.

However, a 64-bit prime wasn’t close to being secure from previously known attacks. So, with confidence that the code was correct, the next test was to see whether the implementation was efficient enough to recover private keys on serious SIDH instances. Could it keep up with the Magma implementation?

Monkeying around with cache optimisation

Running the same attack on the SIKE challenge, the code worked but it was incredibly slow. Something along the way was inefficient as our prime grew, so the new task was to try and identify the sluggish code and clean it up. Profiling the script, most of the run time is spent in JacToJac(). This isn’t surprising, as it’s run approximately 100 times for each oracle call, so it is expected to be dominant in the profiling. However, the recorded slow-down from the baby SIDH parameters seemed much more significant that one would expect by approximately tripling the bit-size of the prime.

With some further analysis, the dramatic slowdown of the algorithm was identified. The root of the problem was due to a SageMath performance issue where rather than caching FiniteField objects they are reconstructed every time they are called. The function JacToJac() is particularly effected due to the heavy use of the group law for the Jacobian of a hyperelliptic curve.

When testing equality of points, the code invokes GF(p^k)(...) for all coefficients. The constructor of the FiniteField includes a primality test of p for every call. As this is called on every coefficient of every point when performing arithmetic operations, we’re constructing objects and performing primality tests thousands of times. The larger the prime, the more expensive this construction becomes.

Rémy decided to fix this issue this by patching SageMath itself, modifying sage.categories.fields so that the vector space is cached:

from sage.misc.cachefunc import cached_method

def vector_space(self, *args, **kwds):

This ensures that each distinct vector field is constructed only once.

With this fix, the implementation broke the $IKEp217 challenge in only 15 minutes. Not bad when compared to the purported Magma time of approximately 5 minutes.

Bridging last gap took: 6.489821910858154
Bob's secret key revealed as: 5xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx2
In ternary, this is: [0, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, 1]
Altogether this took 795.5218527317047 seconds.
sage SIKE_challenge.sage 785.42s user 22.78s system 101% cpu 13:19.19 total

Overnight, Rémy also ran the attack on the SIKEp434 parameter set. The secret key was recovered in only an hour and a half, amazing result when the Magma implementation took approximately one hour!

Bridging last gap took: 14.06521987915039
Bob's secret key revealed as: 107365402940497059258054462948684901858655170389077481076399249199
In ternary, this is: [2, 1, 2, 1, 1, 0, 1, 2, 0, 2, 1, 0, 1, 2, 2, 2, 1, 0, 2, 1, 0, 2, 1, 2, 2, 2, 1, 1, 1, 0, 0, 2, 2, 0, 1, 1, 2, 2, 2, 0, 2, 1, 0, 1, 0, 0, 0, 0, 0, 0, 2, 2, 0, 2, 0, 0, 2, 1, 1, 1, 0, 0, 2, 1, 2, 1, 0, 2, 1, 2, 1, 0, 1, 1, 0, 2, 1, 0, 2, 1, 0, 0, 1, 1, 0, 0, 2, 2, 2, 0, 2, 2, 0, 1, 1, 1, 0, 0, 0, 2, 1, 0, 2, 0, 1, 0, 1, 0, 1, 2, 1, 2, 2, 0, 0, 0, 0, 0, 0, 0, 2, 0, 0, 1, 0, 0, 0, 1, 1, 2, 0, 1, 1, 1, 0, 1, 1]
Altogether this took 5233.838165044785 seconds.

The next morning, inspired by these results, the goal was to find a way to have this same performance without directly patching SageMath. The motivation for this reimplementation was to allow people to run the code themselves and it was important to make this as easy as possible.

A gentler fix was to set the flag proof.arithmetic(False) in the code. This globally tells SageMath to use (among many things) a much faster, probabilistic primality test. We’re not worried about false positives this could (very rarely) introduce, as we are working with a known, fixed prime. As an example of how dramatic this speed up is, a primality test of a 1024 bit integer is more than 1000 times as fast:

sage: p = random_prime(2^1024)
sage: time is_prime(p)
CPU times: user 2.83 s, sys: 13.4 ms, total: 2.85 s
Wall time: 2.86 s
sage: proof.arithmetic(False)
sage: time is_prime(p)
CPU times: user 2.1 ms, sys: 0 ns, total: 2.1 ms
Wall time: 2.11 ms

This doesn’t address the construction of the vector space again and again, but by dropping the expensive primality test on every call the hope that it’s fast enough (or at least a good start).

By including the proof flag into the script, SIKE_challenge.sage broke the $IKEp217 challenge in 30 minutes without any additional patches:

Bridging last gap took: 9.461672067642212
Bob's secret key revealed as: 5xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx2
In ternary, this is: [0, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, x, 1]
Altogether this took 1799.0663061141968 seconds.

However, while this code was running Robin Jadoul found a way to achieve the same result as Rémy’s SageMath patch with the following in-line monkey patch by including

Fp2.<i> = GF(p^2, modulus=x^2+1)
type(Fp2).vector_space = sage.misc.cachefunc.cached_method(type(Fp2).vector_space)

This ensures the vector field is cached as in Rémy’s patch, but the fix can be done during run time. This allows all users of the script to get the speed up without modifying the SageMath source. This is a really important fix, so huge thanks to Robin. Without it, the hardest parameter sets would have been out of reach without hard-patching SageMath.

Optimising using mathematics

The next set of performance enhancements are thanks to Rémy’s optimizations of the function JacToJac(). This is the obvious place to focus as it’s where the attack spends most of its time. Optimisations can be viewed in the following pull requests:

Accumulatively, these performance enhancements are fantastic and we see more than a 3-times speed up for the code, pushing the SageMath implementation to be more performant than the Magma implementation!

Optimising using better SageMath practices

The last speed ups came from running profilers on our code and adjusting how objects were called to avoid slowdown from how Python was constructing and manipulating polynomials, points and Jacobians and isogenies. A non-exhaustive list of tricks we used:

  • Hard-code dimension of curve #10
    • When constructing the Jacobian of a hyperelliptic curve, an expensive, redundant computation of the curve’s dimension is performed (a curve’s dimension is always 1). We applied a monkey patch to address this.
  • Twice faster Jacobian quotients #13
    • Using points rather than polynomials for the isogeny kernel uses Vélu’s formulas rather than Kohel’s formulas, which are faster.
    • Elliptic isogenies were made more performant by passing the known degree as an optional argument and removing the internal validity check.

Breaking SIDH on a laptop

To celebrate, let’s look at the recored runtimes of our implementation across all parameters.

Vanilla 🍦 No Proof 😴 Monkey Patch 🐵 Current Version 🏃🏻💨
Baby SIDH (SIKEp64) 1 minute 1 minute 1 minute 5 seconds
$IKEp217 Challenge 30 minutes 15 minutes 2 minutes
SIKEp434 1.5 hours 10 minutes
SIKEp503 3.5 hours 15 minutes
SIKEp610 25 minutes
SIKEp751 1-2 hours
All recorded times were achieved on a MacBook with Intel i7 CPU @ 2.6 GHz on a single core. Elements of the table without an entry haven’t been run.

Although most digits of the key can be recovered one by one, the first set of digits must be collected together. For SIKEp64, $IKEp217 and SIKEp434 only the first two digits need to be collected together, with a worst case of 3^2 = 9 calls to the oracle to recover the values.


  • For SIKEp503 the worst case is we make 3^4 = 81 calls for the first 4 digits.
  • For SIKEp610 the worst case is we make 3^5 = 243 calls for the first 5 digits.
  • For SIKEp751 the worst case is we make 3^6 = 729 calls for the first 6 digits.

This means that in the worst case when attacking SIKEp751 more than half of the computation time is spent collecting the first 6 of the 239 digits!

Estimating the running time

We can estimate an average running time from the expected number of calls to the oracle Does22ChainSplit(). This still won’t be totally accurate but gives some rough estimates which seem to agree with our recorded values.

  • For the first \beta_1 digits, at most 3^{\beta_1} calls to Does22ChainSplit() are needed and half of this on average
  • For the remaining b - \beta_1 digits Does22ChainSplit() is called only once when j = 0 and twice when j = 1 or j = 2. It is then expected on average to call the oracle once a third of the time and twice for the remaining two thirds of the digits.

Expressing the approximate time cost of a single call of Does22ChainSplit() as c, the estimate the total cost can be expressed as:

\displaystyle \textsf{Cost} = c \cdot \frac{3^{\beta_1}}{2} + c \cdot \frac{(b - \beta_1)}{3} + 2c \cdot \frac{2(b - \beta_1)}{3}

Which looks slightly cleaner written as:

\displaystyle \textsf{Cost} = c \left(\frac{3^{\beta_1}}{2} + \frac{5(b - \beta_1)}{3} \right), \; \; \textsf{Worst Start} = c \left(3^{\beta_1} + \frac{5(b - \beta_1)}{3} \right)

Parameters c \beta_1 Average Cost Worst Case Start
SIKEp64 0.2s 2 5 seconds 7 seconds
$IKEp217 1s 2 2 minutes 2 minutes
SIKEp434 3.4s 2 13 minutes 13 minutes
SIKEp503 4.5s 4 22 minutes 25 minutes
SIKEp610 6s 5 43 minutes 1 hour
SIKEp751 8.4s 6 1.75 hours 2.6 hours
Here, c has been estimated using a MacBook Pro using a Intel Core i7 CPU @ 2.6 GHz. Note: as c was benchmarked from the first oracle calls, these are over-estimates, as the oracle calls become faster as more digits are collected.


As a community, the plan is to keep working on our implementation, attempting to make the code more readable and performant. The end-goal is for this implementation to be a valuable resource that students and researchers can use to learn about this truly beautiful attack.

Furthermore, the community should continue to work together on SageMath. It’s an incredible resource, and the hope is that this blog post is an indication of how versatile and powerful it can be at implementing very high-level mathematics.

Some of problems we encountered along the way have already been submitted to be taken into the next release of SageMath. In particular, Lorenz Panny has fixed the need for including the monkey patch for the Finite Field caching.

The performance enhancements that we have included in our implementation just show how much more room there is to develop this attack and our understanding of the relationship between elliptic curves and higher dimensional Jacobians in cryptanalysis.

Congratulations to Wouter Castryck and Thomas Decru!

What’s next for isogenies?

  • With only a preliminary version of the attack on eprint, it will take the full paper, and community research time to really understand how far the Castryck-Decru attack can be generalised.
  • Unlike some historic attacks, simply increasing key sizes for SIKE is not sufficent. If SIDH is to reappear as a cryptographic protocol, it will need a design overhaul to remove all structure which this attack relies on for key recovery.
    • As this blog post is edited, a proposal to modify SIDH to protect against this attack: Masked-degree SIDH by Tomoki Moriya has appeared on eprint.
  • Other isogeny protocols such as CSIDH and SQISign seem to be safe from this attack. This is because neither of these protocols have a known secret isogeny degree or the image of the torsion points in public data.
  • More generally, the appearance of such a brilliant attack on a cryptosystem that stood unbroken for a decade will shake confidence in constructing protocols using isogeny problems. From the experts, the message is that there’s a lot of research to do now, which can only lead to more exciting results.


Many thanks to Rémy Oudompheng for collaboratoring with me on this project and teaching me so much about higher-genus isogenies. My additional thanks to Rémy Oudompheng and Lorenz Panny for feedback on my description of the attack, and my collegues at NCC Group: Paul Bottinelli, Kevin Henry, Elena Bakos Lang and Thomas Pornin for their valuable feedback on an earlier draft of this blog post.

Higher Education Institution Finds Easier, Better Scanning with NodeZero

8 August 2022 at 20:05

When the Desert Research Institute (DRI) of Reno, NV, a higher education organization focusing on applied environmental research, needed a way to run penetration testing and vulnerability scanning at an affordable cost, they found NodeZero.

“DRI is a soft money funded organization, so we are always budget focused, and what drew us to [Horizon3.ai] was the ability to get a full featured, easy to use pentest program at a price we can afford. The fact that NodeZero is autonomous makes things significantly easier,” says Ryan Coots, Information Security Officer with DRI. “We don’t have to pay a red team to do an expensive, in-person comb-through of our security controls.”

DRI had used other products before, but found that after a one-year deal, the price would jump to an unaffordable price point.

“And then we’d have to start over with a new tool,” says Coots.

DRI has a highly segmented environment with approximately 100 different subnets, giving them about 5,000 IP addresses across all their networks and campuses. NodeZero has helped with keeping their network secure, as well as improving visibility across the board.

“We have a couple of non-centrally managed IT groups at DRI that have the ability to spin up their own network servers, and we don’t always have deep visibility on those machines. Where NodeZero helps us here is we can now scan those servers, find exploitable vulnerabilities and misconfigurations, and work with those groups to remediate them,” says Coots.

Where NodeZero Excelled

DRI looked at several competing products, all of which were strictly
vulnerability scanners.

“NodeZero is more of a pentest tool that uses vulnerabilities to try and exploit actual gaps that exist in systems,” says Coots. “The difference is NodeZero takes it one step further to try to actually carry out an attack in a safe manner. As this is all done via A.I. and an easy-to-use dashboard, this serves our needs well.”

Other products simply scan against a database of vulnerabilities, he says.

“Additionally, NodeZero looks for weak credentials and other holes, vulnerabilities, or misconfigurations an attacker could use to break into the system,” says Coots, whereas NodeZero has a more complete process.

“It’s very easy to set up and use, very affordable, and has very few issues with penetration testing and scanning,” he says.

Another benefit to NodeZero: while it runs an intense test, it doesn’t tax resources or interrupt the workflow of the end users, which DRI had found with other products.

“Other scans are very aggressive and in-depth and can knock out a system or cause a disruption – we haven’t had that with NodeZero,” says Coots.

The Benefits of External Pentesting

DRI was quick to make use of NodeZero’s external pentesting option when released in early 2022.

“That was a huge help,” says Coots. “Previously we had to coordinate with an outside group or even pay to have our public subnets externally scanned. The ability to launch my own external pentest has been extremely useful to us. We’ve already run one with great results, remediated any issues and then verified the remediations worked. That ability to verify a fix is one of the biggest features for us.”

As a Design Partner, Coots had shared the desire for external pentesting with the Horizon3.ai team previously, who he says is always responsive and open to suggestions and feedback.

How DRI uses NodeZero

Coots has enabled a small, junior team to run NodeZero pentests, but all of IT has read-only access so they can review the hosts, operations, and remediation options. This fosters relationships between the IT staff and helps
them focus on security.

“They can see: Here’s a vulnerability, here are the remediation options, and here’s why we should go fix it,” says Coots.

One-click verification of remediation has been a significant benefit for ensuring when something is fixed, it truly is fixed, explains Coots.
“There is no more ‘I think I’ve fixed this issue’ – now we run a 1-click verify op and confirm that it’s fixed,” he says.

The short learning curve to use NodeZero has helped make it a success for DRI, Coots explains.

“It’s pretty much; you have a Docker instance, you give it an IP range to scan, and off it goes – the automation is critical when you have a small staff,” he says.

This has enabled DRI to run pentests more often. They’ve been running 40-plus tests monthly at this point, and Coots is working on a recurring quarterly schedule.

“I scan 100 different network segments a quarter, when the scans are complete, we then combine the results into a spreadsheet and sort by severity which is based on how NodeZero classifies them. We’re able to start from the top down and remediate,” says Coots.

Coots uses NodeZero to improve the scanning process for DRI’s highly segmented environments. Since NodeZero is fully containerized, it is portable and easy to configure for multiple network segments.

This allows Coots to scan segments as if there were no protections in place in each segment.

“With the setup now, I take the firewall out of the equation,” says Coots. “I put the NodeZero container in the same subnet I am scanning, and because the scan is contained within the same network segment, it doesn’t trigger the firewall which would normally limit the results of any vulnerability or pentest scan. The result is a much more in-depth scan and a real look at vulnerabilities and exploits within a network segment. We’re able to get significantly more information out of each operation.”

The post Higher Education Institution Finds Easier, Better Scanning with NodeZero appeared first on Horizon3.ai.

Congratulations to the MSRC 2022 Most Valuable Researchers!

8 August 2022 at 17:30
By: msrc
The Microsoft Researcher Recognition Program offers public thanks and recognition to security researchers who help protect our customers through discovering and sharing security vulnerabilities under Coordinated Vulnerability Disclosure.  Today, we are excited to recognize this year’s top 100 Most Valuable Researchers (MVRs) based on the total number of points earned for each valid report. Congratulations …

Congratulations to the MSRC 2022 Most Valuable Researchers! Read More »

Small-time cybercrime is about to explode — We aren't ready

8 August 2022 at 12:42

The cybersecurity industry tends to focus on extremely large-scale or sophisticated, state-sponsored attacks. Rightfully so, as it can be the most interesting, technically speaking.

When most people think of cybercrime they think of large-scale breaches because that's what dominates the headlines. However, the problem is much bigger. In 2021, the Internet Crime Complaint Center (IC3) received a staggering 847,376 complaints, with each victim losing a little more than $8,000 on average. Once you account for the high-value breaches, the true impact is even lower. The average person is far more likely to have their identity stolen or fall victim to some other sort of scam than be directly affected by a large-scale breach — and business is booming.

A deeper look at the data from IC3 shows that the amount of complaints and revenue being generated from cybercrime continues to rise. Interestingly there is a huge jump in cybercrime during the pandemic with a staggering increase of more than 60% in complaints between 2019 and 2020, with it increasing further in 2021. It's clear that cybercrime is on the rise, but what's driving it?

There have been a variety of reports that criminals are turning increasingly to cybercrime instead of traditional drug crimes, with which they were commonly associated in the past. This is both a blessing and a curse — it removes a lot of violence and crime from the streets but is adding a significant amount of pressure on local law enforcement. This is an international problem. Several recent reports highlight that this is also an issue in Italy and Spain.

There are cybercriminals everywhere and the U.S. is no exception. What's changed is who is involved. Historically, cybercrime was considered white-collar criminal behavior perpetrated by those that were knowledgeable and turned bad. Now, technology has become such an integral part of our lives that anyone with a smartphone and desire can get started in cybercrime. The growth of cryptocurrencies and associated anonymity, whether legitimate or not, has garnered the attention of criminals that formerly operated in traditional criminal enterprises and have now shifted to cybercrime and identity theft.

Cybercrime is a local law enforcement problem

For cybercrime to get the attention of national law enforcement, it needs to rise to a certain level. In most cases, that means the monetary value of the crimes. Effectively, a criminal needs to steal a lot of money to get the attention of the FBI or other national law enforcement agencies — and criminals know it. The majority of the cybercrime street criminals are operating in doesn't garner the attention of national law enforcement, since it's much easier to cash out a small payday than it is to cash out large lump sums of cash. A criminal can walk into a big box store and buy a couple hundred dollars worth of gift cards using a stolen credit card relatively easily. Trying to cash out the $100,000 in Bitcoin they just stole in a scam is much more challenging.

The wave of cybercrime that's coming isn't going to be targeting huge multinational corporations looking for millions of dollars, it's going to scam folks out of their tax return or sign them up for fraudulent unemployment benefits. One thing that might become increasingly popular is the return of identity theft and associated credit card fraud. Ransomware cartels dominate the headlines with the tens or hundreds of millions of dollars they are taking in, but it's the low-level criminal compromising those around you that will be an urgent challenge in the months and years ahead.

Quantifying criminal activity presents challenges with interesting results

The IC3 data clearly shows that cybercrime is on the rise, but can it be correlated with a decrease in other forms of crime, or is it net-new bad actors? When initially looking at this topic, we were curious if there are trends pointing to reduced crime rates in some categories. The thought is that as more criminals move into cybercrime, we would see reductions in other types of crime. However, not all crime is created equal, and the challenge becomes, "How do you compare criminal behavior?" We started looking at the types of felonious crime that are commonly prosecuted in America and there were two big buckets of potential crossover criminals: violent crime and drug crime. We decided to focus specifically on felony drug crime since both drug and cybercrime tend to be non-violent offenders but wanted to include the violent crime landscape to see if there have been any noticeable shifts.

Being in a pandemic means we needed to look at a larger dataset extending beyond the pandemic, as some of the data could be skewed. Granular data on crime isn't widely available, but some of the larger police departments in the U.S. do publicly expose some of that data, most notably the New York Police Department. These larger cities are often considered a bellwether for the way the country as a whole will shift in the months and years ahead.

The NYPD breaks out data in a variety of categories, including various types of felonies. We focused specifically on the non-seven major felony offenses that included felonies for drugs and weapons. To avoid biased data from the pandemic, we began looking at the data beginning in 2013 and ending with the end of 2021, as the 2022 data is still being gathered. The resulting data paints a pretty clear picture of how crime has changed in the past eight years.

Clearly, the amount of drug felonies over the past eight years has dropped off drastically before stabilizing during the pandemic. Interestingly, over the same period, the amount of weapons-related felonies has stayed largely static, with small shifts from year to year. The question then becomes, "Did a large number of people decide to stop committing crime or have criminals moved into different criminal ecosystems?"

It seems unlikely that we would see this significant dropoff in drug crime, especially as the percentage of people abusing drugs hasn't likewise dropped significantly. It's important to note that shifts in cannabis laws may have affected the number of arrests, but cannabis wasn't fully legalized in New York state until March 2021.

Additionally, initial data indicates that some crimes including murder, assaults, robberies and grand larceny thefts are decreasing. Major cities in the U.S. reported decreases in said crimes between 30% and 42% following the implementation of stay-at-home orders due to COVID-19. Although the problem may have been exacerbated during the pandemic, it's been around a lot longer.

A recent Forbes article notes that this behavior is a trend that started about a decade ago but has since begun to accelerate. Street gangs are moving away from drugs and toward fraud fueled by cybercrime in the U.S. and around the world. These criminals can operate in two different modes: one where they are actively gathering the data which can require specific expertise in technology, hacking, and malware or the data can just be bought. There are numerous forums where enterprising criminals can buy stolen data including names, addresses, social security numbers and other relevant information required to commit fraud and identity theft. Then, the issue is just monetizing it, and business is booming.

The fact that it is typically a smaller monetary crime makes it easier to accomplish. From a criminal's perspective, it's far easier and safer to take a stolen credit card and buy a $500 gift card from a big box store than it is to launder and process $10,000 stolen through similar means. The larger the denomination and the larger the scale, the more likely you are to draw the interest of federal law enforcement, who have far deeper pockets and much more sophisticated capabilities when it comes to prosecuting cybercrime. The pandemic has introduced additional avenues of fraud that criminal gangs have capitalized on, including COVID-19 relief funds and associated unemployment benefits fraud. In addition to the increases in available funds, the application processes were moved online to ensure the health of those involved, a boon for would-be criminals. Combining these with the already ongoing fraud and identity theft crime and the amount of money these groups are obtaining is significant.

Law enforcement challenges lie ahead

This brings us to the organizations tasked with bringing this new wave of cyber criminals to justice: law enforcement. However, since the majority of this crime is small time, the majority of the responsibility is going to fall on local law enforcement instead of state or federal agencies that tend to cover more significant financial crimes. Unfortunately, that benefits the criminals in some ways. Local law enforcement has many challenges they face daily, including drug and violent crime, to which they are highly trained. These types of arrests can be dangerous and require a very specific skill set.

Cybercrime, on the other hand, is a completely different type of problem to deal with. Instead of breaking down doors and dodging gunfire, law enforcement officers are pouring over data from the criminal themselves and the organizations/people they target with their fraud, trying to tie together transactions to build a solid, forensically sound case.

The real challenge lies in how to effectively deal with these two problems that require completely different skills. This is the dilemma that local law enforcement departments face in the coming years. As we are all aware, information security professionals are highly sought after and can demand significant compensation, and training existing law enforcement officers on how to build cases of cybercrime can be challenging.

Law enforcement can take some cues from private industry here. One trend we are increasingly seeing to address the security talent shortage is to look elsewhere in your organization for those with a penchant for security and the investigative drive necessary to succeed. There are ample investigators inside police departments, look for those with skills in online-based investigations and leverage them for cybercrime in the future.

Additionally, looking to the youth in your community could be another powerful resource for building a talent pipeline. Building relationships with existing computer science programs or high schools in the area to identify this talent could be a great resource. We're already seeing this applied around the world. For instance, in the UK, an investment of seven million pounds in a single year helped lead to the creation of cybercrime units in every police force in England and Wales.

There aren't any easy answers here, but likely will require a shift in the way we handle policing in the future. As more criminals begin to hide beyond keyboards and phones, away from the streets, traditional law enforcement is going to have challenges and what may initially appear to be a reduction in certain types of crime may be accompanied by a similar spike in fraud and cybercrime that isn't as easy to quantify. The future of policing is going to require an increased ability to identify and prosecute more high-tech crime, while still maintaining control over potential drug and violence issues in the jurisdiction.


As we've seen repeatedly over the years, we don't typically see new types of crime, just crime taking new forms. The world today is run by technology and it is becoming an ever-increasing part of our lives, as such, criminal activity is bound to increase. Criminals may seem like they are just out to commit crimes, but in reality, most criminals are choosing to live a life of crime to support themselves and their families. They, like anyone else, are familiar with risk assessment and now it may make more sense to commit crime with a keyboard instead of selling drugs as the risks are lower across the board. It's a lot less likely to draw immediate law enforcement response and there typically aren't turf wars in cyberspace and if they are they tend to be less violent. Furthermore. the margins in cybercrime are significant and in the end the goal is to make as much money as quickly as possible: technology is the key to scale and speed.

Law enforcement, especially at the local level, is going to need to evolve along with the criminals as they are tasked with protecting the general public. The future criminal is going to be aware of operational security and technologies like Tor to make their arrests increasingly difficult. The time is now to start building the capabilities into police departments to be able to handle the shift that has already been happening for a decade but is poised to explode, as people have been locked away for several years during the pandemic. The question becomes — how did criminals make use of that time?

Microsoft Office to publish symbols starting August 2022

8 August 2022 at 09:30
By: msrc
We are excited to announce that Microsoft Office will begin publishing Office symbols for Windows via the Microsoft Public Symbol Server on August 9th 2022. The publication of Office symbols is a part of our continuing investment to improve security and performance for customers and partners. Key Advantages for customers, partners, and Microsoft Security: Empowering …

Microsoft Office to publish symbols starting August 2022 Read More »

Hacking mobile networks has gotten a lot more interesting with 5G and Open RAN

Cloud security is often the weakest link in modern 5G networks according to our red team hacking assessments. Telcos have an opportunity now to embrace cloud security best practices and make 5G networks much more hacking resilient.

Fuzzing WeChat’s Wxam Parser

7 August 2022 at 19:30


WeChat (if you haven’t heard of it) is a super popular chat app similar to the likes of WhatsApp, and runs on iOS, Android, Windows and MacOS.
Being a chat app, it handles various file formats like images and videos, and also propriety formats like “Wxam” (which honestly I haven’t researched before so you’ll see how I approached that).

You’ll also see below some of the challenges I had in my harnessing of the target and how my initial fuzzer framework I chose had to be replaced due to lack of support for certain functionality that WeChat used (and how I debugged this).

Researching the Target

Now that we know what WeChat is we can look at how I decided to write a fuzzer (in 1 day!) for this target!
It started by deciding I wanted to blog about fuzzing something, previously I’ve had blogs on Logic bugs and I wanted to balance that with some cool fuzzing target I haven’t looked at before, so I started by browsing ZDI to see if any displayed targets were interesting.

I noticed a few entries for WeChat like the below:

ZDI WeChat bug disclosures

Now at this point I know what WeChat is, but I have no idea what WXAM is (but its safe to guess its some format that gets parsed).

So my next step was to simply install WeChat in a VM! Note that here I’m targeting the Windows build of WeChat, for the following reasons:

  1. I want this to be quick, its primarily for this blog post and I know I can fuzz Windows targets faster than iOS/Android

  2. If this parser also exists on other platforms, it probably isn’t much different (potentially if I find the bug on Windows, it’ll exist on the other platforms)

Now its installed and I have a bunch of executables and DLL files in C:\Program Files (x86)\Tencent\WeChat, so how do I find the WXAM parsing functionality?

Finding the Target

A good starting point may be to dump all the imported & exported functions from all the executables and DLLs and search for anything with the name “wxam” in it, but I went a different route — I simply guessed and opened the DLL that sounded interesting in IDA!

For me, looking at the list of DLLs I spotted “WeChatWin.dll”, this sounds like a main DLL for WeChat that handles certain Windows specific APIs or something? Who knows, but it stood out more than some of the other DLLs, so I opened this in IDA.

This DLL took a while to load, its pretty large (~40mb), once done the first thing I did was search in functions, imports & exports for the name “wxam”, there I found:

wxam2pic imported function shown in WeChatWin.dll

We spot an imported function named “wxam2pic” that lives in “VoipEngine.dll” — nice! This is a great starting point, it even sounds like a parser.

Before I look at wxam2pic in VoipEngine, I first examine cross-references to this import within WeChatWin.dll and see how WeChatWin uses this, I spot two functions that call this, including this one:

Usage of wxam2pic in WeChatWin.dll

Scrolling to the top of this function we spot:

Don’t you love debug prints?
This string alone implies the function we’re looking at is a “WxAMDecoderHelper”, specifically this function handles the “DecodeWxam” functionality — Awesome! This is exactly the type of function that corresponds with the ZDI entries we saw.

There’s something else notable about this function, look at how IDA shows the prototype:

Its a custom calling convention!

This means if we were to target this function for fuzzing directly, we’d have to match this custom parameter passing convention instead of Visual Studio’s provided options (fastcall, cdecl, etc).

Instead, I took a look at the function that calls this function, and I got:

(Note: ignore the function name itself, I named it this from what I saw!)

Nice, this function uses a standard calling convention (fastcall), takes only two arguments and calls the DecodeWxam function (handling the custom calling convention for us!)

We also see from the debug print that this function appears to decode the Wxam and then re-encode it as a jpeg, this would be a great function to fuzz!

(Note: There’s another decoder that transforms the Wxam to a GIF! We’re not going to look at that one in this blog, but its essentially the same).

Reversing the Target Function

Alright so I want to fuzz this function as it appears to take a Wxam file and parse it, lets analyze the parameters.

Lets view cross-references to this function to see how its called:

(Note: I named the read_file function myself, if you open this function you see a simple CreateFile + ReadFile operation on the provided fName variable!)

From this, I see the following:

  • A filename is provided to the function I myself named “read_file” and a buffer is returned in v11

  • The buffer and a value is passed to “isWxGF”, this function reads a header and the flag to determine if we should parse it further or not

    • Actually, turns out the input structure is a format of a 32bit input buffer pointer followed by a 32bit size of input. So isWxGF takes (pBuffer, buf_sz)

  • If we pass the “isWxGF” check, we call the decoder function passing through:

    • The address of an input structure that contains (pBuffer, buf_sz), the pseudocode looks similar to

      • InputStruct inputStruct = (pBuffer, buf_sz)

      • Where the first input to the decoder function is a pointer to our inputStruct

    • A pointer to a int containing the value 0

      • This pointer seems to be some output from the decoder, if its non-zero its assumed to be another valid pointer

This seems super easy to fuzz:

  • We can fuzz using shared-memory mode in a fuzzer like WinAFL

  • Our fuzz function will:

    • Call isWxGF; and if successful:

    • Calls the decoder

So I wrote a harness to do this in WinAFL, however:

This usually means our program is crashing before reaching the our fuzz function.

So I run WinAFL under WinDBG and see an invalid address dereference when trying to load the “WeChatWin.dll” file!

I analyze the DLL entry point and spot:

I see, this DLL uses CRT (also thread-local storage) — this causes issues with DynamoRIO (which I was using with WinAFL).

This can be confirmed by compiling my executable with CRT support and noting that WinAFL crashes before our process main executes at all!

So this means we can’t use DynamoRIO, our options include:

  • Using WinAFL in IntelPT mode (I’m using an AMD CPU, so no go here)

  • Use a different fuzzer

Well I chose a different fuzzer.

I could have gone the snapshot route with Nyx or what-the-fuzz, instead I decided to try Jackalope

This has a very similar command line to WinAFL, and uses TinyInst for instrumentation (no DynamoRIO!)

Upon trying this, it worked:

Its fuzzing, and we are getting new coverage!

At this point I stopped, I got the fuzzer working well enough I was happy for the day, next steps would include:

  • Analyzing coverage, ensuring we’re not hitting any roadblocks

  • Check stability / determinism, ensure there’s no globals we need to reset

    • Or just throw this into a snapshot fuzzer

  • Reverse the WXAM format and create better corpus, and a format-aware mutator

Also note that in the isWxGF function, I noted the header bytes it checks for and ensured my initial corpus had that header (so we start with an input that successfully passes that check).

There are other things I did in the harness, which are general fuzzing things like obtaining the non-exported function pointers to our target functions we wanted to fuzz.

I’ve included the harness I used below, along with the Jackalope command line I used to kick off fuzzing, feel free to take this and expand on it or view coverage to see how far it gets!

Overall this was a fun half a day exercise at quickly writing a basic fuzzing harness based on some ZDI entry.

Update — Android Bugs!

So, turns out some of the bugs I found from this fuzzer were reproducible on Android:

@h0mbre_ @domenuk ezpz? pic.twitter.com/CiLoUxQtb5

— Christopher (@Kharosx0) August 8, 2022


I put all the files on my Github: https://github.com/Kharos102/BasicWXAMFuzzer

Want to Learn Fuzzing?

We offer Vulnerability Research & Fuzzing trainings live or self-paced (For our self-paced trainings, see: https://signal-labs.thinkific.com/collections)

For any questions, feel free to contact us!

Threat Roundup for July 29 to August 5

5 August 2022 at 19:54

Today, Talos is publishing a glimpse into the most prevalent threats we've observed between July 29 and Aug. 5. As with previous roundups, this post isn't meant to be an in-depth analysis. Instead, this post will summarize the threats we've observed by highlighting key behavioral characteristics, indicators of compromise, and discussing how our customers are automatically protected from these threats.

As a reminder, the information provided for the following threats in this post is non-exhaustive and current as of the date of publication. Additionally, please keep in mind that IOC searching is only one part of threat hunting. Spotting a single IOC does not necessarily indicate maliciousness. Detection and coverage for the following threats is subject to updates, pending additional threat or vulnerability analysis. For the most current information, please refer to your Firepower Management Center, Snort.org, or ClamAV.net.

For each threat described below, this blog post only lists 25 of the associated file hashes and up to 25 IOCs for each category. An accompanying JSON file can be found herethat includes the complete list of file hashes, as well as all other IOCs from this post. A visual depiction of the MITRE ATT&CK techniques associated with each threat is also shown. In these images, the brightness of the technique indicates how prevalent it is across all threat files where dynamic analysis was conducted. There are five distinct shades that are used, with the darkest indicating that no files exhibited technique behavior and the brightest indicating that technique behavior was observed from 75 percent or more of the files.

The most prevalent threats highlighted in this roundup are:

Threat Name Type Description
Win.Dropper.TrickBot-9958804-0 Dropper TrickBot is a banking trojan targeting sensitive information for certain financial institutions. This malware is frequently distributed through malicious spam campaigns. Many of these campaigns rely on downloaders for distribution, such as VB scripts.
Win.Ransomware.Cerber-9958814-0 Ransomware Cerber is ransomware that encrypts documents, photos, databases and other important files. Historically, this malware would replace files with encrypted versions and add the file extension ".cerber," although in more recent campaigns other file extensions are used.
Win.Virus.Xpiro-9958895-1 Virus Expiro is a known file infector and information-stealer that hinders analysis with anti-debugging and anti-analysis tricks.
Win.Dropper.Remcos-9960040-0 Dropper Remcos is a remote access trojan (RAT) that allows attackers to execute commands on the infected host, log keystrokes, interact with a webcam and capture screenshots. This malware is commonly delivered through Microsoft Office documents with macros sent as attachments on malicious emails.
Win.Dropper.Shiz-9958984-0 Dropper Shiz is a remote access trojan that allows an attacker to access an infected machine to harvest sensitive information. It is commonly spread via droppers or by visiting a malicious site.
Win.Dropper.HawkEye-9959777-0 Dropper HawkEye is an information-stealing malware that targets usernames and passwords stored by web browsers and mail clients on an infected machine. It is commonly spread via email and can also propagate through removable media.
Win.Worm.Kuluoz-9959792-0 Worm Kuluoz, sometimes known as "Asprox," is a modular remote access trojan that is also known to download and execute follow-on malware, such as fake antivirus software. Kuluoz is often delivered via spam emails pretending to be shipment delivery notifications or flight booking confirmations.
Win.Dropper.DarkComet-9959797-1 Dropper DarkComet and related variants are a family of remote access trojans that provide an attacker with control over an infected system. Capabilities of this malware include the ability to download files from a user's machine, mechanisms for persistence and hiding, and the ability to send back usernames and passwords from the infected system.
Win.Dropper.Ramnit-9960101-0 Dropper Ramnit is a banking trojan that monitors web browser activity on an infected machine and collects login information from financial websites. It can also steal browser cookies and attempts to hide from popular antivirus software.

Threat Breakdown


Indicators of Compromise

  • IOCs collected from dynamic analysis of 46 samples
Mutexes Occurrences
5502606391408671395 4
32899542343072484998 4
1124524871971925691 3
24112587554236391103 3
39744624822682236206 3
23819686304274202058 2
31572222973474305701 2
38648211142506533958 1
33656147683147949452 1
7918010151544240523 1
38748932962513239244 1
Domain Names contacted by malware. Does not indicate maliciousness Occurrences
wequinc[.]pl 4
patardd[.]pl 4
rydedun[.]pl 3
boristh[.]pl 3
lionopp[.]pl 3
matesic[.]pl 2
zanouns[.]pl 2
beryofn[.]pl 1
cabolth[.]pl 1
risiert[.]pl 1
githyet[.]pl 1

File Hashes

01a4f86457a252ffc23117ba653a2093902d0160140a3fda03e3cb9595f6d652 04a8a18b801bf158717c49444c3148f56fb1c23b6781b589106b848fad13557f 04d4ecf05a7bcc6ca0f318bacaa6087ea1e5badc14ca9eebec52aaff791718bc 08a004e94ce71ee0d239e38242283544f530996f4785924f85616040b278bef4 094f5c76889cd9f3f9357d72eda49a962eedc8457a77d586459dbd5968f85aef 0c25f673e25e8c9bb066ae56c41a83e28ef40a9da8327c9f7cd09f663b9a4614 0ef6c2cc035d61abd0f221d2bb8d6c0f5fc1e2e87cd5001f47861435fded326b 12eb4eb5dd38c776ec50166596c5e4ffda47108ce709990ae84a33a3a91776ed 1f14d617fd53588a36cd26c19e6f306fad28bac24140e9083986bb0cac607bc5 2184130eb8a891000fee1e343a5634531d72e05a7893fbafd6d53e52350bae19 23d19c57bacf51421505125da6917c815a1aa0d5c7346cf42c47f6667df0599d 2549d2a70d146340d14d981ecd9c33ce384bc743d4ed258f1eb9740c30792429 26851fc35426f83e70d1542cc4f00a3dd16222de418d2e0727a4ab9d5218c22b 28d1f82ea2f237ae643e442adae17449dadb8ad93397bf2299b0b53abeee45cb 2d05858c463ea267870ff964d9f9779def1ca711586dcfea58745ebe6675ff1f 2d1e5cc0f414d6cc94ec251605c68c32c442740e129d7af97f8293844aecca6a 30636b11d051121251b2051971223e6e294dfaf917338239deb5b8edf5bce20b 39d4446bb6b1c8cbf319fe02f1316897f22a6b00633af1b7e6159dbd7b837556 3a0c89d07193ae260ced7a04873117af0213c43407248d2ff7edf95bd3b32421 3b5e722ae23b3656cfb17fcb9fd218b92c5e4f24c241c3f1c37bded99d92c035 3f32a6229d93292633dc3c9af4dcf7360463cd9fcc72bfc68bfc68afa666316d 4f47c12806778d27afa43905ebb5b2079a451da93237899167d6420333cfe9a8 50543f06717e0d022a4b58043861f0a38ab82e068f07414adc5be142a66c6cec 513125bc77c78f24fc6a29a125c0d5373d5b365f476ba496f90d8dc952fd4441 5584279c960a9a7aeb97ececdb90adc01da3dab0f1fe1cbf8c10e67f14d19c0d
*See JSON for more IOCs


Product Protection
Secure Endpoint This has coverage
Cloudlock N/A
CWS This has coverage
Email Security This has coverage
Network Security N/A
Stealthwatch N/A
Stealthwatch Cloud N/A
Secure Malware Analytics This has coverage
Umbrella N/A

Screenshots of Detection

Secure Endpoint

Secure Malware Analytics



Indicators of Compromise

  • IOCs collected from dynamic analysis of 16 samples
Registry Keys Occurrences
Value Name: Run
Value Name: AutoRun
<HKCU>\PRINTERS\DEFAULTS\{21A3D5EE-E123-244A-98A1-8E36C26EFF6D} 16
Value Name: Component_01
Value Name: Component_00
Value Name: fc
Value Name: fc
Value Name: ntoskrnl
Value Name: ntoskrnl
Value Name: grpconv
Value Name: grpconv
Value Name: hh
Value Name: hh
Value Name: WerFaultSecure
Value Name: WerFaultSecure
Value Name: javaws
Value Name: javaws
Value Name: at
Value Name: at
Value Name: Dism
Value Name: Dism
Value Name: sc
Value Name: sc
Value Name: expand
Mutexes Occurrences
shell.{381828AA-8B28-3374-1B67-35680555C5EF} 16
IP Addresses contacted by malware. Does not indicate maliciousness Occurrences
85[.]93[.]0[.]4 16
85[.]93[.]0[.]118 16
85[.]93[.]0[.]2/31 16
85[.]93[.]0[.]92/30 16
85[.]93[.]0[.]96/28 16
85[.]93[.]0[.]112/30 16
85[.]93[.]0[.]116/31 16
85[.]93[.]3[.]224/27 16
85[.]93[.]4[.]0/25 16
85[.]93[.]4[.]128/26 16
85[.]93[.]4[.]192/27 16
85[.]93[.]4[.]224/29 16
85[.]93[.]4[.]232/30 16
85[.]93[.]4[.]236/31 16
85[.]93[.]39[.]8/29 16
85[.]93[.]39[.]16/28 16
85[.]93[.]39[.]32/27 16
85[.]93[.]39[.]64/26 16
85[.]93[.]39[.]128/25 16
85[.]93[.]40[.]0/21 16
85[.]93[.]48[.]0/24 16
85[.]93[.]49[.]0/25 16
85[.]93[.]49[.]128/28 16
85[.]93[.]49[.]144/31 16
Files and or directories created Occurrences
%APPDATA%\{6F885251-E36F-0FE6-9629-63208157D7A2} 16
%APPDATA%\Microsoft\Windows\Start Menu\Programs\StartUp\fc.lnk 2
%APPDATA%\{6F885251-E36F-0FE6-9629-63208157D7A2}\fc.exe 2
%System32%\Tasks\fc 2
%APPDATA%\Microsoft\Windows\Start Menu\Programs\StartUp\ntoskrnl.lnk 1
%APPDATA%\{6F885251-E36F-0FE6-9629-63208157D7A2}\ntoskrnl.exe 1
%APPDATA%\Microsoft\Windows\Start Menu\Programs\StartUp\WerFaultSecure.lnk 1
%APPDATA%\{6F885251-E36F-0FE6-9629-63208157D7A2}\WerFaultSecure.exe 1
%APPDATA%\Microsoft\Windows\Start Menu\Programs\StartUp\ndadmin.lnk 1
%APPDATA%\{6F885251-E36F-0FE6-9629-63208157D7A2}\ndadmin.exe 1
%System32%\Tasks\ndadmin 1
%APPDATA%\Microsoft\Windows\Start Menu\Programs\StartUp\grpconv.lnk 1
%APPDATA%\{6F885251-E36F-0FE6-9629-63208157D7A2}\grpconv.exe 1
%System32%\Tasks\grpconv 1
%APPDATA%\Microsoft\Windows\Start Menu\Programs\StartUp\sdchange.lnk 1
%APPDATA%\{6F885251-E36F-0FE6-9629-63208157D7A2}\sdchange.exe 1
%System32%\Tasks\sdchange 1
%APPDATA%\Microsoft\Windows\Start Menu\Programs\StartUp\at.lnk 1
%APPDATA%\{6F885251-E36F-0FE6-9629-63208157D7A2}\at.exe 1
%System32%\Tasks\at 1
%APPDATA%\Microsoft\Windows\Start Menu\Programs\StartUp\hh.lnk 1
%APPDATA%\{6F885251-E36F-0FE6-9629-63208157D7A2}\hh.exe 1
%System32%\Tasks\hh 1
%APPDATA%\Microsoft\Windows\Start Menu\Programs\StartUp\javaws.lnk 1
%APPDATA%\{6F885251-E36F-0FE6-9629-63208157D7A2}\javaws.exe 1
*See JSON for more IOCs

File Hashes

13cb0416ecaedac2d05c117c68d7745d2f2ef8d2e41a5522ae28a9fdbe1cc464 18e9f9e0f0584b662165a2c78ca155ec06b59f48bfb09655929aaf6e4d3e04b6 273e649cfa2dba65d23094955a8901b2d8bcabd9d883eb53db97da09b2dc7257 37ce9b3d448b8d7ced3c71deebe8a826aa27095d155bbb08f5fe945edcaa665d 396c12c17e7de26873a87c37724b30ebeee8a246cb9f4dd8c81c4eb28e5a36ec 62e12d7f62c7c9826d8b20334d6bf5a9b9367cc92735c4c0ee0b9b04c68ebb30 636bb6784c21658f113ea4dcc00a82f0aa2c1e68927f3bb398d57ab5fcb6bc53 7017f1de73c8949efa7b04eb9973d73b712af738d2faf268cf32be7dea92b136 73fd26b7ee1d7939a55ee17a0ea15fc4a3aa85d417f9d19ec33230e71d21ac11 80574eb815087be8ead2c679474b8cf100a5a4db41cd3e012eff0c3e50ed900a 910aad5d8e14a47c2882531c587ceb7836af31e2c09296c43877a3ed2cc044e6 a340be1e9fe2140662c6bb04f1280eb91b1b1b1bd76c8e484ab4058ff25d5cf3 c41250c29a915060c509cb390c8dac68029067c1537707742ed211866ae2bff4 caba5cbc3931965b5f478934e02d20775413e15bcc559a684c632cfa9b151583 f6c4639bcabd34e8b2e9cf8323e07416a11bc4d579b910405880a8950128cfb1 fc73adec96749e88de8fb29777f1b4c27439c24690236857576076f545c8deb5


Product Protection
Secure Endpoint This has coverage
Cloudlock N/A
CWS This has coverage
Email Security This has coverage
Network Security This has coverage
Stealthwatch N/A
Stealthwatch Cloud N/A
Secure Malware Analytics This has coverage
Umbrella N/A

Screenshots of Detection

Secure Endpoint

Secure Malware Analytics



Indicators of Compromise

  • IOCs collected from dynamic analysis of 37 samples
Registry Keys Occurrences
Value Name: HideSCAHealth
Value Name: Type
Value Name: Type
Value Name: Type
Value Name: Start
Value Name: Type
Value Name: Start
Value Name: Type
Value Name: Start
Value Name: Type
Value Name: Start
Value Name: Type
Value Name: Start
Value Name: Type
Value Name: Start
Value Name: Type
Value Name: Start
Value Name: EnableSmartScreen
<HKLM>\SOFTWARE\WOW6432NODE\MICROSOFT\SECURITY CENTER\SVC\S-1-5-21-2580483871-590521980-3826313501-500 37
<HKLM>\SOFTWARE\WOW6432NODE\MICROSOFT\SECURITY CENTER\SVC\S-1-5-21-2580483871-590521980-3826313501-500
Value Name: EnableNotifications
Value Name: Start
Value Name: Start
Value Name: AccumulatedWaitIdleTime
Value Name: RootstoreDirty
Value Name: AccumulatedWaitIdleTime
Mutexes Occurrences
kkq-vx_mtx61 37
kkq-vx_mtx62 37
kkq-vx_mtx63 37
kkq-vx_mtx64 37
kkq-vx_mtx65 37
kkq-vx_mtx66 37
kkq-vx_mtx67 37
kkq-vx_mtx68 37
kkq-vx_mtx69 37
kkq-vx_mtx70 37
kkq-vx_mtx71 37
kkq-vx_mtx72 37
kkq-vx_mtx73 37
kkq-vx_mtx74 37
kkq-vx_mtx75 37
kkq-vx_mtx76 37
kkq-vx_mtx77 37
kkq-vx_mtx78 37
kkq-vx_mtx79 37
kkq-vx_mtx80 37
kkq-vx_mtx81 37
kkq-vx_mtx82 37
kkq-vx_mtx83 37
kkq-vx_mtx84 37
kkq-vx_mtx85 37
*See JSON for more IOCs
Files and or directories created Occurrences
%CommonProgramFiles%\Microsoft Shared\OfficeSoftwareProtectionPlatform\OSPPSVC.EXE 37
%CommonProgramFiles(x86)%\microsoft shared\Source Engine\OSE.EXE 37
%ProgramFiles(x86)%\Microsoft Office\Office14\GROOVE.EXE 37
%ProgramFiles(x86)%\Mozilla Maintenance Service\maintenanceservice.exe 37
%SystemRoot%\Microsoft.NET\Framework64\v2.0.50727\mscorsvw.exe 37
%SystemRoot%\Microsoft.NET\Framework64\v4.0.30319\mscorsvw.exe 37
%SystemRoot%\Microsoft.NET\Framework\v2.0.50727\mscorsvw.exe 37
%SystemRoot%\Microsoft.NET\Framework\v4.0.30319\mscorsvw.exe 37
%System32%\FXSSVC.exe 37
%System32%\UI0Detect.exe 37
%System32%\alg.exe 37
%System32%\dllhost.exe 37
%System32%\ieetwcollector.exe 37
%System32%\msdtc.exe 37
%System32%\msiexec.exe 37
%System32%\snmptrap.exe 37
%System32%\sppsvc.exe 37
%System32%\vds.exe 37
%SystemRoot%\ehome\ehrecvr.exe 37
%SystemRoot%\ehome\ehsched.exe 37
%SystemRoot%\Microsoft.NET\Framework\v2.0.50727\ngen_service.log 37
%SystemRoot%\Microsoft.NET\Framework64\v2.0.50727\ngen_service.log 37
%SystemRoot%\SysWOW64\dllhost.exe 37
%SystemRoot%\SysWOW64\msiexec.exe 37
%SystemRoot%\SysWOW64\svchost.exe 37
*See JSON for more IOCs

File Hashes

013aa31a250e2858846c6f078e12a5132abbc0fad271365d3b67527fa2c2f402 05c2e245c5f3a325472cf34f42093931e48d181c0f17caf9add2b35e7a3e828c 0aee33737e3213c74bb671a1ab7b9485e00ade57ade144e2be354f67506a7290 0af8855eff016554c3ddf0ce82bb61859ac3986ee4136ee06e7fe5d5a6d89788 0ca2f5ca6ce21bacf1b26601c214a36766a0c911320bec0c184b5a18923ece23 128d57cca2eae54f5754a5f1730a05df82d942a11764d0595e6c920498e9565f 1397eff74a13595ea3fcb206a76977d1447997680fdf81163c2b985a009b080c 13dd82a41add2789b1ea617cded11cf9bdbc143082372dcc2b26b2ae2616dbba 14e5e9016d589d815058b09845af3b2fc2781b9815a493499664f29e9832e9fa 16fcdd9f0950eda4799c80afd354767feefb725c58d82022c2d1385e25d48e96 1b0665bd149dd3b9ae9a3b19c7be06b5ddcd53da461f91cda65365b94b7a288b 1cf200ce049a09ea6f18ff56f65c651d519d6096d6eaf94331351c1217d2e002 1f98e6f12d028379751c4e5f6efe96e0fe8a286c7448513dda93c980e3d8acf6 26bd53dc56ec5c20627d67c8bdce2f67c3325bd6421a87319e3694abcf73867e 28664a444ff8d844816b801fcf92199100cad7375ebaedea96020b2f7e2c664b 290be865ff04b744f3f34e17cded589f11519cb10d5d186535cd5a21de8dd650 29e70dc26eb00d9ff16ed8864b2583dde97e70d6f7dc074c50f3665ad7f8b2dc 2c52d85ad0e41acf5112bccbbdde281950692c0e100e499a15b170d66d0154d0 30ed57cfe6626a3e05de88be3207d4524311c62a6a2b5647f9359a620ed22f11 3134096945a4cea5132ea9d0ad9b1a6925da40d2d4e86c8f8c8f4d3795b962ca 35f44b47ad1e072f2030291462cedd654234eb0575883ae8f8d5978c051d78e1 35fcd428c89e9586460cb2701ca4cb378824a32d497366a96fa234caf54d8048 3c8477fdcd2719855d6b38cf29849d36dca6bf90805f996286bf77fff7ba1fa3 3eb5cdb190ee1efbea012512c3ed6afd6215473bf208a1853f37701a3f7ba13a 3f53b25ccced470ef2b1eb2edb4b839099a0ca597f4dbcc3aa590b260d727ab0
*See JSON for more IOCs


Product Protection
Secure Endpoint This has coverage
Cloudlock N/A
CWS This has coverage
Email Security This has coverage
Network Security N/A
Stealthwatch N/A
Stealthwatch Cloud N/A
Secure Malware Analytics This has coverage
Umbrella N/A

Screenshots of Detection

Secure Endpoint

Secure Malware Analytics



Indicators of Compromise

  • IOCs collected from dynamic analysis of 21 samples
Registry Keys Occurrences
Value Name: LanguageList
Value Name: FaviconPath
Value Name: Deleted
Value Name: DefaultScope
Value Name: {761497BB-D6F0-462C-B6EB-D4DAF1D92D43}
Value Name: licence
Value Name: @C:\Windows\system32\DeviceCenter.dll,-2000
Value Name: @explorer.exe,-7001
Value Name: mea
Value Name: exepath
Value Name: exepath
Value Name: licence
Value Name: Un9
Value Name: exepath
Value Name: licence
Value Name: re
Value Name: dr
Mutexes Occurrences
Remcos_Mutex_Inj 3
Local\55C37268-60E9-964A-3299-E2046F3CC613 2
Remcos-SFLVDU 1
Remcos-1MSE40 1
Remcos-A21G8J 1
IP Addresses contacted by malware. Does not indicate maliciousness Occurrences
13[.]225[.]214[.]71 4
13[.]225[.]214[.]108 4
37[.]19[.]193[.]217 3
95[.]211[.]75[.]16 2
162[.]210[.]195[.]111 1
13[.]225[.]214[.]91 1
Domain Names contacted by malware. Does not indicate maliciousness Occurrences
piloresi[.]top 7
dioneras[.]top 7
downloadmirror[.]intel[.]com 5
uniresio[.]top 4
emperimen[.]com 3
www[.]bing[.]com 2
busyboydesign[.]xyz 2
toptoptop2[.]site 1
toptoptop3[.]site 1
toptoptop3[.]online 1
toptoptop2[.]online 1
lutheatre[.]com 1
fallium[.]com 1
sheaffic[.]com 1
Files and or directories created Occurrences
%SystemRoot%\win.ini 21
%LOCALAPPDATA%\Administrator 8
%HOMEPATH%\kmm 1
%HOMEPATH%\kmm\Cam.exe 1
%HOMEPATH%\kmm\Cam.vbs 1
%HOMEPATH%\Dul\Slu6.exe 1
%HOMEPATH%\Dul\Slu6.vbs 1
%HOMEPATH%\Uds\sov.exe 1
%HOMEPATH%\Uds\sov.vbs 1
%HOMEPATH%\Sv9\BUT.exe 1
%HOMEPATH%\Sv9\BUT.vbs 1
%HOMEPATH%\ref 1
%HOMEPATH%\ref\Bar.exe 1
%HOMEPATH%\ref\Bar.vbs 1
%HOMEPATH%\ma\No.exe 1
%HOMEPATH%\ma\No.vbs 1
%HOMEPATH%\Oxy\Bru4.exe 1
%HOMEPATH%\Oxy\Bru4.vbs 1
%HOMEPATH%\tr\TEL.exe 1
%HOMEPATH%\tr\TEL.vbs 1
*See JSON for more IOCs

File Hashes

1990701e4db9f573be94dbfd0e9edcb826c4a0ba858b42249812acb12cea572f 201ecff5a0b06b1401158972176bf3af310e1a25a9f603ea902b340f15262130 667fcc41313580c1c5dd3f74e84f13a4431a8b1daf4e1c60d5f3ab0c657e95ef 6754bcad108371e4192bc126187cf7ac07c39ea3f5ed7d975402a4c20d7fbcd4 68183c5baad715853bf2a38a2384288803a431ef4881be8c33b473f7e97d0186 6f70b508bcf39a1de4371f080c51bbf569ff5be7bf0f91793519c3c511710386 72d305998919d0c14d44659c0427e1130b9cf6539f386d328879c7d416ac085a 7cbbe9909fc023294a209ecf1b3882a02cb198d6841a129471201ce105c10d7f 905d2ba08aa3c839dfb815a373c5e2d0ae71badcbb1a70be1ef2683381dcb257 96eba5d5846bbcb803ffbac64ea5adf52fcb736ebda11abd466d509314dcc216 c2bfc250e5a0f8047d8eeb2bab36669e2d20becf57ddfa1e0ff5c33ff63864d5 cad62477913555b37902a162c9b437af27182fb219aa14647f257a0c48ddd556 d2a181619dc5bce7506d65bd893b411772de00c9ffdcbbcb9e3a78ab029a4997 d6e619e7f6f7578cef21ad4bea1ed94f397c0063aee69df329bc0aab3ea0b177 d9f6c0ffc135785c9c0355bad4cc4b8884f6f655c6e336c14b1b7a27568ddda9 dcd1f707b263fe1c37b94944b8399d92675d215d76aca304f0c7455250627d68 e9877a7c8d2daca6b15131b26a583695e4d5e2c05023b764f24a551666055b0a f22c91af53fd11dae4ebeeca1886c5a3355f68970cb554be7eb10affbb547341 f57f13ef3d153621588b9aa9a273e08a77069dd2b9b7d5ad08c579f24feedc41 f7ac5679a471bbc48cb5af2fd54ea2e4621f7e825c06fba59a1690fa6745e56f fd4de71e56062003053b8f93f6bb84188666361a07c415e56a4b015802237289


Product Protection
Secure Endpoint This has coverage
Cloudlock N/A
CWS This has coverage
Email Security This has coverage
Network Security This has coverage
Stealthwatch N/A
Stealthwatch Cloud N/A
Secure Malware Analytics This has coverage
Umbrella This has coverage
WSA This has coverage

Screenshots of Detection

Secure Endpoint

Secure Malware Analytics



Indicators of Compromise

  • IOCs collected from dynamic analysis of 88 samples
Registry Keys Occurrences
Value Name: 67497551a
Value Name: 98b68e3c
Value Name: userinit
Value Name: System
Value Name: load
Value Name: run
Value Name: userinit
Mutexes Occurrences
Global\674972E3a 33
Global\MicrosoftSysenterGate7 33
internal_wutex_0x000000e0 33
internal_wutex_0x0000038c 33
internal_wutex_0x00000448 33
internal_wutex_0x<random, matching [0-9a-f]{8}> 29
internal_wutex_0x000007d0 12
IP Addresses contacted by malware. Does not indicate maliciousness Occurrences
13[.]107[.]21[.]200 16
45[.]33[.]23[.]183 9
96[.]126[.]123[.]244 8
198[.]58[.]118[.]167 7
45[.]56[.]79[.]23 6
45[.]33[.]30[.]197 6
45[.]79[.]19[.]196 5
173[.]255[.]194[.]134 5
72[.]14[.]178[.]174 5
72[.]14[.]185[.]43 4
45[.]33[.]2[.]79 3
45[.]33[.]18[.]44 3
45[.]33[.]20[.]235 2
85[.]94[.]194[.]169 1
Domain Names contacted by malware. Does not indicate maliciousness Occurrences
fodakyhijyv[.]eu 33
qekusagigyz[.]eu 33
maxyjofytyt[.]eu 33
xudylenyrob[.]eu 33
pufepepazyd[.]eu 33
vopibycywow[.]eu 33
fotoxysupyd[.]eu 33
gaqehysohec[.]eu 33
lyxaxududes[.]eu 33
rycovuvutiq[.]eu 33
kevimudyqec[.]eu 33
jewidonevin[.]eu 33
tulekuvigij[.]eu 33
vocupotusyz[.]eu 33
galavozaxog[.]eu 33
divufozutog[.]eu 33
kefidaxupif[.]eu 33
jejykaxymob[.]eu 33
xutevexecif[.]eu 33
puryxepenek[.]eu 33
lysowaxojib[.]eu 33
dimigesupew[.]eu 33
fobatesohek[.]eu 33
ryhadyvigis[.]eu 33
qekikyvutic[.]eu 33
*See JSON for more IOCs
Files and or directories created Occurrences
%TEMP%\<random, matching [A-F0-9]{1,4}>.tmp 33

File Hashes

0426a2801b985679944d7956d57df0c195e4871cb5fa9ae5d3cb864600883613 06748264e401a4fcf30a802df0f390a75a14a3ff6148b8f064ee3e2585c742d9 09bf6eb80568c5d370d52e77ca1eddea41f0eb7e458549c994620b3e6af3967c 0affbf8c7691eaaab70491418b6db92cced36ff4a0a482673a4ebdd5492ad6c8 0fbe21b7ff8392a707d0d871494c2298e88e723ebcd7a4495c6a037232d4899b 11b3839df1c31d6c2f15591a0fa013c8b41862dd522d106c85876b49e7d561c0 11b6cfd9b8f56c8107511151282335f7b5f5d555665bec7506908515dcb6acab 11c19ec5a341f6a6bfa86170ea383439466f008ff42ec6dc04bd0445a658ba63 1641e6a92c47304c11521b9c875029a387e49b511438b3ac4c122ee7b14519de 1cac14ca2ad5715132446d1bb0503a6f783577d15f8fb97611dac9b7177903cc 1f4e2901cf95c9ca682d9e5c24235c11da57a47153969203e58b5528bd37b411 1f83440aab9dc62a6c4726b35ee58355b1cf76d23d194250397069423b17d281 237bf6bd91b6301dd01456859507771ed5fc2eda62f67e207bea6928f69573b9 253dc24fa6384c2c2757acc74ecfb88a231ab434c718e5b044a47e3fec4515f7 25525b728590f243275c528727c4887c3521fc16c25f60e3b364fb21e8b64dab 2553d02ff7f59fc5e0830783a508b4a5e8daff585bb4e5411c49bb34217f1b3d 259d0e1eb7a6ab82cfef210054b7cedd069d331455d6c0effff450c514fef6b1 2796098904f867adffd735f528461e5fb8be9f33ebd22bc37fb58684c3476112 27de5dc0ae67097bc22a0bcb3381dcebc372c469c4b8effe2b83d87f85f01cc1 2a6f60367dc3d70d2db9926e28dba4d79f20e319ceaf839c094cf85c9850c99a 2c729b76866357b2fae9d51f4d5f69c1554b18b5be35f896300631b7409e49e7 319155806bbb3e74cc753ed768a13455965e1fa7a175155f5862c2e030c2e35a 34b2879998dfd238977cf19e5f4e3d4cbccfa61a9b0688e43a569e19a75a2844 3578be24b2fe30600747846c30c1e286622e1906fce1a801e10b87117bf37ef4 385ddefdb0c298b4cd194b165f82e9ddec8c8e6616160e432125e576dae5603c
*See JSON for more IOCs


Product Protection
Secure Endpoint This has coverage
Cloudlock N/A
CWS This has coverage
Email Security This has coverage
Network Security This has coverage
Stealthwatch N/A
Stealthwatch Cloud N/A
Secure Malware Analytics This has coverage
Umbrella This has coverage
WSA This has coverage

Screenshots of Detection

Secure Endpoint

Secure Malware Analytics



Indicators of Compromise

  • IOCs collected from dynamic analysis of 15 samples
Registry Keys Occurrences
Value Name: Hidden
Value Name: Windows Update
Value Name: Shell
<HKCU>\SOFTWARE\[email protected] 3
<HKCU>\SOFTWARE\[email protected]
Value Name: NewIdentification
<HKCU>\SOFTWARE\[email protected]
Value Name: NewGroup
<HKCU>\SOFTWARE\[email protected]
Value Name: FirstExecution
Mutexes Occurrences
<random, matching '[A-Z0-9]{14}'> 4
X43238C48CI4NY_SAIR 1
M21V21V8G7Q66R_SAIR 1
Global\07657600-129e-11ed-9660-0015174b6151 1
IP Addresses contacted by malware. Does not indicate maliciousness Occurrences
104[.]16[.]155[.]36 6
104[.]16[.]154[.]36 5
77[.]88[.]21[.]158 2
142[.]251[.]16[.]109 2
208[.]91[.]199[.]224 1
208[.]91[.]198[.]143 1
208[.]91[.]199[.]223 1
192[.]99[.]212[.]64 1
Domain Names contacted by malware. Does not indicate maliciousness Occurrences
whatismyipaddress[.]com 11
kalashas[.]no-ip[.]biz 3
smtp[.]gmail[.]com 2
smtp[.]yandex[.]ru 2
mail[.]siliconsss[.]com 2
smtp[.]impexservicesindia[.]com 2
smtp[.]vsnl[.]net 1
smtp[.]thanawalagroup[.]net 1
Files and or directories created Occurrences
%APPDATA%\pid.txt 11
%APPDATA%\pidloc.txt 11
%TEMP%\holdermail.txt 10
%APPDATA%\WindowsUpdate.exe 10
\Sys.exe 3
\autorun.inf 3
E:\autorun.inf 3
%TEMP%\Administrator7 3
%TEMP%\Administrator8 3
%TEMP%\Administrator2.txt 3
\directory 3
\directory\CyberGate 3
\directory\CyberGate\install 3
\directory\CyberGate\install\server.exe 3
%APPDATA%\Administratorlog.dat 3
%TEMP%\SysInfo.txt 3
%APPDATA%\Windows Update.exe 3
E:\Sys.exe 3
%System32%\drivers\etc\hosts 1
%TEMP%\oUK6NMZIZls5Ku6i.exe 1
%APPDATA%\g3h44Njnele2nJzi 1
%APPDATA%\g3h44Njnele2nJzi\ZOqlaWVQEXMz.exe 1
%APPDATA%\hAtRUbl2c5ywfar3 1
*See JSON for more IOCs

File Hashes

04e516d05c22e5489ba47b5e1bd03f6cb8bcf2b084e2b3dae23acbe25d4b4591 21e52c431fce5ea651800127be440f447fafd20c3d74f34b0d712e140b0c138d 21e949c72bc90a7b4647b305dd306e343f732ad2b898dba5e9b920edc33fc9a0 220c6f3ffe28c8c7cd3f3b669b47bccdde30b200ab1de9bd0cca55c475ad62cb 2f656303daecf2322749ed2a4b69b7124433dfea94d658c9e1e18d415db16456 32a841f8eaf7fa85d3c78469a9890988c1c9b90c97cfba674ac8f9f991bd3a94 4000b5bce992bdbdd73174fbe1e8d9b0fd65ad6c88f282889a8604dfa9fe0f59 5291c5d0bd7eaee2402fb660be1b8501c3a712471e9d66062b6728794909263a 5393c5a558225a02a03ee8ea46968d53a72b57194261e17dc7e35f0bd9b630ea 628eb845ab8309303d0ebb7448063dbafd36954a66596977a272d5806cacaeca 656d25151b846944e11c7ba03ce4fae066f7a8c29cdce84d0b241d4305a4245c 6d155125192252b756c6af33bca25810ab9a19be347e5793b534802662eb00a4 9a8797b6c2753e70ce0888185473510f40d3c0ff45b81b639dc8c077cb3679ec ad52ce9456cb87f713ad43de89835e0c882fd3a77389bb41ab50396efd59088a c4bf7dbe799d71e8e16c1aa5ca3f3af04f174b91e1a357a02e38b0155a46a600


Product Protection
Secure Endpoint This has coverage
Cloudlock N/A
CWS This has coverage
Email Security This has coverage
Network Security This has coverage
Stealthwatch N/A
Stealthwatch Cloud N/A
Secure Malware Analytics This has coverage
Umbrella This has coverage
WSA This has coverage

Screenshots of Detection

Secure Endpoint

Secure Malware Analytics



Indicators of Compromise

  • IOCs collected from dynamic analysis of 26 samples
Registry Keys Occurrences
<HKCU>\SOFTWARE\<random, matching '[a-zA-Z0-9]{5,9}'> 26
Value Name: uecguckk
Value Name: ujaduqcw
Value Name: cuhmadmx
Value Name: vdqcxwxs
Value Name: lhelwsfg
Value Name: pvgxfqel
Value Name: wrbmmivh
Value Name: cdjmiong
Value Name: agokwqgv
Value Name: fpesjwgk
Value Name: bomrkrmk
Value Name: lsekxadg
Value Name: bxvvsgvr
Value Name: wudcreed
Value Name: snwmmmvf
Value Name: dfvkflcs
Value Name: dlirvvqw
Value Name: csfqppjx
Value Name: imcfhgpa
Value Name: oqpeifcm
Value Name: lhxptbjv
Value Name: durqeakc
Value Name: hsrhcrvj
Value Name: htpvdufk
Mutexes Occurrences
2GVWNQJz1 26
IP Addresses contacted by malware. Does not indicate maliciousness Occurrences
173[.]203[.]97[.]13 15
76[.]74[.]184[.]127 13
37[.]59[.]82[.]218 13
94[.]32[.]67[.]214 13
212[.]45[.]17[.]15 13
142[.]4[.]60[.]242 13
50[.]57[.]139[.]41 12
82[.]150[.]199[.]140 12
92[.]240[.]232[.]232 10
113[.]53[.]247[.]147 10
203[.]157[.]142[.]2 9
176[.]31[.]181[.]76 9
188[.]165[.]192[.]116 7
Files and or directories created Occurrences
%LOCALAPPDATA%\<random, matching '[a-z]{8}'>.exe 26

File Hashes

01d6c50b70eb28d693e74b7ad15158707b8f57a9711e35c07d3d1c4ee7f630ee 08c25287e368a2158b029684e74626ba867a606837cce07ea2837b6ed78857a4 09bb26d956e0eb8aba714e836c041d844ac01eb4ccb3e498382c07ae3e267ff4 0bf1e31c2a0fe232876deef8bad8cbe1e08a3ad377db920ffc27c4852ef1dc89 0c6ec5510575da4416321eb58b20d3e447746e0cea1ffd06241f8a1e6bbb2837 0dd0361ead8f0e962be7a115dd8a4fa9d1a12b88c11633f82cfeae655a59f809 0fb3d456de4717b29c3a332e29a10cc9c52c94c92f6438f32791f5a5785b603b 1052ac160c67084f7dae6af5d9ee545fb0df20b99b8e989177ffb795a32aa35c 192d087160aad1afdb5ed06eb4128d997e578af554a626887746d91e66bc688a 1f4a448e60174255ef3d7492e60464ef4cfd84f65acb8c9824493b71d6864b8f 1f7810a638c2f1825276f2784cf557d7610ca0eabb463d06e6b25597fd077043 230a54a47fed1921adb452b5e88f1467e021dd85aac8f0d60a5a41912b991d28 26cad8fc0603c849db06f59e46b452bb4c3fe5cadfd46e344ce9a7f10365ddb8 276bb12ea62aa7f7ffce0531b84bbe1f7f2e6a19f4150ca6a7b1c69f4662b595 286bc1cee4c188350c8bb50812e30f7bec0b794efca5a2eb0b12368b479211b3 2938109eee69fe708fa15752e0723d110a01ee4e3e1e804cc97bbde01267fdb8 2a850531aeb725e5f138b9b1158640fe41c05a25560e2550fa2b070d96490a8e 31266599481409d70b317821d5af1aea693e7c1c7cedd04fd5dec0008bd816a7 384b51772d288e63038e146446e6e84b1f737cd3d8d34c3871d875fda77ff29a 38e1edffa779f9e2dd16104c35fc7a6c4a21dff7f3ad9bc8233b5817e8666441 3949d166ce5f75648fcb66ea3f9aaf251aa9847d576aef7d10b2830a295e2096 3ffee22fa7f00e260b92385c8cda56eee17c133b7c47cb33cf701d0c9e2ae89e 419c33660b59de42d150f8c1163873db94fa59e8d684bb44d0ec866eaebd00a7 441c34ba7b9ee2d7b0506013a2fb9fd5c5b517d38a66e1228edf4d7e1e20b9e8 446d8276a7008c24317b101c5d7050da5f1a51301a47842cd35f5d8a362eee83
*See JSON for more IOCs


Product Protection
Secure Endpoint This has coverage
Cloudlock N/A
CWS This has coverage
Email Security This has coverage
Network Security N/A
Stealthwatch N/A
Stealthwatch Cloud N/A
Secure Malware Analytics This has coverage
Umbrella N/A

Screenshots of Detection

Secure Endpoint

Secure Malware Analytics



Indicators of Compromise

  • IOCs collected from dynamic analysis of 11 samples
Registry Keys Occurrences
Value Name: EnableLUA
Value Name: AntiVirusDisableNotify
Value Name: UserInit
Value Name: MicroUpdate
Value Name: LanguageList
Mutexes Occurrences
Domain Names contacted by malware. Does not indicate maliciousness Occurrences
zapto666[.]zapto[.]org 11
sildelanoe2[.]zapto[.]org 11
Files and or directories created Occurrences
%ProgramData%\Microsoft\Windows\Start Menu\Programs\MSDCSC 11
%ProgramData%\Microsoft\Windows\Start Menu\Programs\MSDCSC\msdcsc.exe 11

File Hashes

236c360d988e5b28b1a4eee229d0f3b5baa203043fc5ae8f016519f753e6b6bf 27990599b2e3ae192d5a897ed30cb98a20eae1d3ed8506dac8d82fef9ed9442e 53cd48d7d092d55fdc35966cfbd01861bf7304f9dc694237d322ff189adb32a4 55754ae53d9555a67d25be9cd73b5d85141d4ef43cd55ae2cf237be1cfa0d965 5dcd64134e33496cdd5ad13012b35834164d59d470a17359710a335469fdf35a 6e0d5bd7c55c9ec287377f8cadd342768c887a8901d015253996112442ff5d6f a53ebd4f480bdf3cf2199692af1d27c2864fc5c038fefed214688416cc2a1066 acaf2d6a74e24b2ab85338fa62efc85d76f6ec9c1cd11657230d975fd0dcde42 c4c677ab5115a0a568d1817528005ad24d0dc06ddd9d738d5f1fb75a3074b3f0 d2e83abd3d779b825e4088f53b43aa8521131a9ebd0dad8006e70fcc0e249e8d eea1adee202040b2c06dfb226eacd4c662b57714f44ffcc0561ff8cb2ec2a6d6


Product Protection
Secure Endpoint This has coverage
Cloudlock N/A
CWS This has coverage
Email Security This has coverage
Network Security N/A
Stealthwatch N/A
Stealthwatch Cloud N/A
Secure Malware Analytics This has coverage
Umbrella N/A

Screenshots of Detection

Secure Endpoint

Secure Malware Analytics



Indicators of Compromise

  • IOCs collected from dynamic analysis of 15 samples
Registry Keys Occurrences
Value Name: EnableLUA
Value Name: AlternateShell
Value Name: Userinit
Value Name: WlkSgauv
Value Name: Type
Value Name: ErrorControl
Value Name: ImagePath
Value Name: DisplayName
Value Name: WOW64
Value Name: DeleteFlag
Value Name: Start
Mutexes Occurrences
{79345B6A-421F-2958-EA08-07396ADB9E27} 15
{7934684F-421F-2958-EA08-07396ADB9E27} 15
{7934723B-421F-2958-EA08-07396ADB9E27} 15
{7934684E-421F-2958-EA08-07396ADB9E27} 15
{<random GUID>} 15
IP Addresses contacted by malware. Does not indicate maliciousness Occurrences
82[.]112[.]184[.]197 15
72[.]26[.]218[.]70 15
195[.]201[.]179[.]207 15
208[.]100[.]26[.]245 15
35[.]205[.]61[.]67 15
142[.]250[.]80[.]14 15
75[.]2[.]18[.]233 15
172[.]105[.]157[.]192 15
46[.]165[.]220[.]150 15
Domain Names contacted by malware. Does not indicate maliciousness Occurrences
kbadlfpgtec[.]com 15
ymcwineqkj[.]com 15
tupexbvpmsc[.]com 15
mwsjitqbf[.]com 15
ccsnpnqxii[.]com 15
dpdadshi[.]com 15
eljmrnwualb[.]com 15
hjxrksvo[.]com 15
lfnjosunfd[.]com 15
paoxlrmbg[.]com 15
qekgxfrk[.]com 15
uhjwxipj[.]com 15
mkmngqxwk[.]com 15
ybmhumhymqj[.]com 15
qopdypfxhda[.]com 15
pfkilgedjhq[.]com 15
sgimiytkanu[.]com 15
leqnxekmi[.]com 15
ieugluxmlx[.]com 15
elieidkolpc[.]com 15
oluddrbaeb[.]com 15
skroackqs[.]com 15
pbfttfgw[.]com 15
ujypninrop[.]com 15
qpvvabbaqcn[.]com 15
*See JSON for more IOCs
Files and or directories created Occurrences
%LOCALAPPDATA%\wblmbpwi.log 15
%LOCALAPPDATA%\xrpatmbf.log 15
%LOCALAPPDATA%\ntqipnfr 15
%LOCALAPPDATA%\ntqipnfr\wlksgauv.exe 15
%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\wlksgauv.exe 15
%TEMP%\dljcankv.sys 15
%TEMP%\oqinictcdtumygeo.exe 15
%LOCALAPPDATA%\ntqipnfr\px1F71.tmp 1
%LOCALAPPDATA%\ntqipnfr\px26AF.tmp 1
%LOCALAPPDATA%\ntqipnfr\px203A.tmp 1
%LOCALAPPDATA%\ntqipnfr\px1CC1.tmp 1
%LOCALAPPDATA%\ntqipnfr\px2B70.tmp 1
%LOCALAPPDATA%\ntqipnfr\px2BFD.tmp 1
%LOCALAPPDATA%\ntqipnfr\px1EB4.tmp 1
%LOCALAPPDATA%\ntqipnfr\px1B98.tmp 1
%LOCALAPPDATA%\ntqipnfr\px2365.tmp 1
%LOCALAPPDATA%\ntqipnfr\px2307.tmp 1
%LOCALAPPDATA%\ntqipnfr\px28A3.tmp 1
%LOCALAPPDATA%\ntqipnfr\px25C5.tmp 1
%LOCALAPPDATA%\ntqipnfr\px2DD1.tmp 1
%LOCALAPPDATA%\ntqipnfr\px2BED.tmp 1
%LOCALAPPDATA%\ntqipnfr\px2529.tmp 1

File Hashes

10df6ef7114ab16c25690d0183960e51d80488690e4f52680be2cf38d4aeb85b 1b39ecf9dc61b7e01c410b02eb8cb5c01ccdb1346474c62d7b916a9fb136681e 25354347217865d4e0a18080a942021de378cdcdff3633edc32583d892639569 265febc90d4163d2d1f29c0f07c8b003002ec7ee9ca4a3f8607ca5364cf06dc3 370c3bdde1b51bf0b9d079e644871b79848ac588c37ea7f89c94a2e2c3103642 3b955ab71c4147497bb1aa0fd65ee9b94bb1cbc897a0be46427f0f66a829de5d 55835f514e7ab6da28a6c69a3ffbe2d356b8ca987a274bc7a190689a57cbfbf2 615c3bfaa531cda8c1ac55bf9d5d93598617cd208702a7ce4c26cd94b2f2d4fd 61657d27b739df7dd856194cc29354ebf9d4a9abe3cb37d8782b5e6bddcba23c 7227840a73bce222d285d89cb1f528a5f5caf230af943a78f85f5e07136f1c4f 91cec64e347f7355c3dabb30b6e70c73d8a16890aa698ef526476930b998dd78 b70d31148f0b79548b7a2fd3a16228b32b0c52432b19b9d651fc9d6f9458c845 b7841d3db93f9a48887fdb82d3492b43f33f36ee8959e4f26a74c77962793e65 e80bad25222ffce33d1fa8c5962b235fecdce744b6dcf9c35db869844802573c ee4d65ec638095b28ec9c1290bf3edac8c767fb2a094c00925fabcde83dfb205


Product Protection
Secure Endpoint This has coverage
Cloudlock N/A
CWS This has coverage
Email Security This has coverage
Network Security This has coverage
Stealthwatch N/A
Stealthwatch Cloud N/A
Secure Malware Analytics This has coverage
Umbrella This has coverage
WSA This has coverage

Screenshots of Detection

Secure Endpoint

Secure Malware Analytics


Reverse Engineering Windows Printer Drivers (Part 1)

Note: This is Part 1 in a series of posts discussing security analysis of printer drivers extracted and installed from public resources. This part explains how we located publicly available drivers distributed by WeWork and conducted initial analysis. Part 2 come shortly after and will cover our exploration with in-depth technical details about how Windows kernel drivers work and the techniques we used to discover bugs in these drivers.

Almost every large organization uses printers, and while the printer market is fairly distributed, it is still heavily dominated by only a few players. Printers need kernel mode drivers to work so that they can communicate through USB and other means, though this is not always the case as modern operating systems are pivoting to user-mode drivers to ensure safety. A vulnerability in a kernel mode printer driver could result in Local Privilege Escalation (LPE) if exploited successfully.

In this two-part series, we’ll discuss the steps we took to analyze these drivers. We’ll also discuss some helpful background information for beginning analysis of Windows kernel-mode drivers.

Step 1. Find Driver Documentation or Public Resources

Since most of the public uses a search engine to find drivers, we will emulate the way a WeWork user would find print drivers so that we can also discuss the implications of using unofficial sources to find installers. The first step we took was to search for documentation and driver downloads in the same way as a user. The drivers found will be used in our analysis. 

What printers does WeWork use?

A quick online search provides these links: 

According to the setup documents, WeWork uses HP, Kyocera and Konica printers. Though this instructional manual seems to be from a non-official source, an attempt to run these installers will be unsuccessful as they expect to be connected to a printer. A search through WeWork’s publicly available documentation shows that for Russian and Chinese WeWork spaces, only the WeWork_HP_installer.exe is documented. It seems that either the other printers are much rarer, or WeWork does not publish documentation publicly.

Step 2. Unpacking Resources

Unpacking Windows Resources

With a bit of web crawling for “WeWork_Installer_HP.exe”, the HP installer executable can be found at https://s3.amazonaws.com/it-assets/printing/wework_installer_HP.exe.

Since this executable contains no digital signature, its origin from WeWork cannot be verified. VirusTotal shows that it is not flagged by any antivirus engines, but they advise to continue on a virtual machine (VM).

The installer does not display a prompt to select where files are stored similar to most common software installers, but we used ProcMon to identify where files are placed on the local machine. Typically, you would first check C:\Program Files or C:\Program Files (x86) for changes. In this analysis, a folder named WeWork_printer_drivers was found in C:\Program Files (x86), which contained two executable files: HP_UPD.exe and win_39754.exe. The files have the following icons displayed in Windows Explorer:

These executables are self-extracting 7-Zip executables and can be opened with the 7-Zip application.

Opening win_39754.exe shows some references to a printer client software known as Papercut, but this does not contain any driver.

Opening HP_UPD.exe (which presumably stands for HP Universal Printer Driver), points to a file directory that contains .inf files for these printers and their properties. See the following documentation for more information on .inf files:


Exploring the files further, there are directories with the name drivers, with each directory containing a subdirectory named either WINXP, WIN2000, AMD64. These directories contain drivers. Out of the directory names, AMD64 is the one most modern architecture for modern day windows operating systems.

Extracting the drivers in this folder, there are 5 drivers:

  • HPZid412.sys
  • HPZisc12.sys
  • HPZipr12.sys
  • HPZius12.sys
  • HPZs2k12.sys

These files all have additional information about them in their properties. Their properties can be viewed by right-clicking on them and selecting Properties->Details, where their descriptions and their original file names are shown.

They seem to be used for implementing the DOT4 (IEEE 1284.4) multiplexing data channel protocol over USB. In fact, the original filenames are references to Microsoft default DOT4 protocol drivers, and the strings of the original Dot4 Microsoft drivers are extremely similar to the HP drivers, almost exact. For more confirmation, BinDiff could be used to check the similarity of the two binaries. 

Unpacking MacOS resources

After an attempt to find the package described in the public facing documents, we settled with the file in the MacOSPrinterSetup instructions, which provides a DMG file.

Opening the DMG file in 7-Zip presents the following directory structure:

Immediately, the most interesting place to find drivers would be the .pkg file that contains the packages which contain binaries. Opening in 7-Zip provides folders:

From the above list of files, the most relevant to kernel drivers would be a KEXT (Kernel Extension), and it seems there is only one relevant package with kext in its name: com.hp.print.ps.kext.pkg. Opening it in 7-Zip results in the files below:

The directory contains these files, the most important of which is the Payload file which contains the actual binaries. We can open this file in 7-Zip and it contains numerous empty path folders which just hold other folders. KEXTs are folders that contain plists (files that describe the KEXT) and the MACH-O binaries. The path to the KEXT in the Payload file is shown below:


This is the path inside the payload to the KEXT contents folder. It provides the directory structure below:

CodeSignature is a directory of signatures for verifying the file. The Info.plist file describes the properties of the KEXT and Version.plist contains version numbers, but where is the binary?

As it turns out, this KEXT is a Codeless Kernel Extension, which can be verified by looking in the Info.plist file containing properties in an XML format. Specifically, KEXTs with binaries contain the CFBundleExecutable property. Inspecting the Info.plist of this KEXT, we find no CFBundleExecutable property.

The purpose of this KEXT is to point the operating system to the subsystems which this hardware device (the printer) uses, and direct it to the NON-KERNEL driver responsible for handling the hardware (IOKit). The XML keys responsible for telling us which pkg is responsible for handling this printer is the USB Printing Class

        <key>USB Printing Class</key>

In the string above, we see a path to a user mode plugin. A word in this path provides a clue into which package contains this plugin. HPDeviceModel, the process used to inspect this plugin, can also be used for the IOKit user mode driver (com.hp.DeviceModel4.pkg / HPIOPrinterClassDriver.plugin). 

Note: Unpacking these macOS driver packages confirms that these drivers are user-mode drivers and not kernel-mode drivers. We did not pursue further analysis on the macOS drivers as the value from attacking them is far less than kernel-mode drivers.

Step 3. Confirmation 

Note: For this step, we will use Windows as it is the only one with Kernel Drivers.

With our research, we now know that the HP drivers are the Dot4 default drivers. This theory can be tested by connecting a printer that supports Dot4 to your computer via USB,and then using a tool like WinObjEx64, which can inspect loaded drivers. 

Browsing the loaded drivers shows:

From the image above, you can confirm that three drivers are loaded: dot4, Dot4Print and dot4usb. The loaded drivers indicate that the operating system is ready to interact with the printer. Despite the fact that there were 5 drivers, it seems (from analysis) that only three drivers are loaded on modern systems. The three files unpacked are: 

  • dot4.sys -> HPZid412.sys
  • dot4prt.sys -> HPZipr12.sys
  • dot4usb.sys -> HPZius12.sys

The binaries for these default dot4 drivers can be found at C:\Windows\System32\Drivers once they have been loaded for the first time.

Devices listed on the system are show in the image below:

While drivers show that the operating system is ready to interact with the printer, it is ultimately up to a user-mode application to initiate a printing sequence. The application can initiate a printing sequence if the drivers present an interactable device to the user-mode application. In the image above, a dot4 device that allows for interaction between user-mode and the driver exists on the system.

Step 4. Architecture and Research

The Windows operating system is massive. It hosts a variety of subsystems, so we focused our research on Windows during analysis. For this research, the goal was to study the different types of drivers and how they affect security. 

Types of Windows Drivers

It’s important to understand that there are several types of Windows drivers and frameworks: 

WDM – The first type of drivers that were created were WDM (Windows Driver Models). This driver is a raw driver and manages resources and devices. When it came to device drivers this seemed to be almost an impossible task due to the endless amount of state that had to be managed, this issue is discussed in depth in old Microsoft archives that can be found here.


KMDF – The Kernel Mode Driver Framework (KMDF) was invented to relieve some of the difficulties developing device drivers, giving developers APIs that would handle edge cases. It implements state machines for PnP, I/O, and others.

UMDF – The User Mode Driver Framework (UMDF) is the user-mode equivalent of KMDF.

WDF – The Windows Driver Framework (WDF) is a term that encompasses KMDF and UMDF.


For this first post in our WeWork printer analysis series, we found resources online and unpacked them. The analysis covered in this post is the initial step in identifying WeWork printer drivers so that we can research further into their security. In the next post, we will look into reverse engineering and attempting to discover exploitable bugs in these drivers. 

The post Reverse Engineering Windows Printer Drivers (Part 1) appeared first on Include Security Research Blog.

Finding hooks with windbg

5 August 2022 at 15:06

In this blogpost we are going to look into hooks, how to find them, and how to restore the original functions.

I’ve developed the methods discussed here by myself and they have been proven to be useful for me. I was assigned to evaluate the security and the inner working of a specific application control solution. I needed a practical and easy solution, without too much coding preferably using windbg. For that I wanted to be able to:

  1. Detect the DLL which performs hooking
  2. Detect all the hooks that it sets up
  3. Restore all the previous instructions (before the hook)

What are hooks?

As hooks is the thing we are looking for let’s briefly talk about what hooks actually are and how they look like.

Specifically we will cover MS Detours.

Basically hooking allows you to execute your own code when the target function is called. It was originally developed to extend the functionality of the functions of closed software. When your code is called by the hooked function it’s up to you what to you want to do next. You can for example inspect the arguments and based on that resume the execution of the original target function if you wish.

To better illustrate how a hook looks like, I’m going to use the picture from the “Detours: Binary Interception of Win32 Functions” document.

MS Detours hook
MS Detours hook

The picture above shows trampoline and target functions, before and after insertion of the detour (left and right).

Of course in order for this to be useful the trampoline function would normally end up calling your custom code, before resuming the target function. For us one important thing to notice is the jump instruction at the beginning of the target function. If it’s there this is a good indicator that a function is hooked.

As we can see, a jump instruction is used to hook a target function and replace the first 4 instructions of the original target function. This results in the target function jumping to a trampoline function and the trampoline function executing the original 4 instructions that were replaced. Then, a jump instruction is used again in the trampoline function to resume the execution of the target function after the jump instruction (TargetFunction+5).

If you’re interested in the official documentation you can find it here and here.

The setup

To better demonstrate the concept, I’ve created a few simple programs.

  • begin.exe – Calls CreateProcess API to start myapp.exe.
  • myapp.exe – Simple program that shows a message box.
  • AChook.dll – Application Control hooking DLL. Simple DLL that forbids any execution of CreateProcessA and CreateProcessW APIs.

First, let’s show these programs in action. Let’s run begin.exe:

begin.exe starts and shows a dialogue that halts execution.
begin.exe starts and shows a dialogue that halts execution.

It shows a message box asking to inject a DLL. This halts execution until the “OK” button is clicked and allows us to take our time injecting a DLL if we want to.

myapp.exe is started by begin.exe.
myapp.exe is started by begin.exe.

Then it launches myapp.exe, which just shows another message box asking if you want to launch a virus. Of course myapp.exe is not a virus and just exits after showing the message box (no matter if the user clicks on “Yes” or “No”).

Now let’s run begin.exe again but this time let’s inject the AChook.dll into it while the message box is shown.

begin.exe waiting for user interaction.
begin.exe waiting for user interaction.

We use “Process Hacker” to inject AChook.dll.

Using Process hacker to inject our DLL into begin.exe.
Using Process hacker to inject our DLL into begin.exe.

AChook.dll also prints some additional messages to the console output:

AChook.dll is injected into begin.exe.
AChook.dll is injected into begin.exe.

When we click now on the OK button, myapp.exe does not run anymore and thus the virus message box is no longer shown. Instead additional messages are printed to the console by AChook.dll.

AChook.dll's hook prevented execution of myapp.exe.
AChook.dll‘s hook prevented execution of myapp.exe.


First we need to identify which DLL is the one that sets the hooks.

To list the loaded DLLs of a running process we use “Process Explorer”.

We select the process begin.exe and press [Ctrl]+[D]:

DLLs loaded by begin.exe in Process Explorer.
DLLs loaded by begin.exe in Process Explorer.

Now we can look for any DLL that looks suspicious. In this case it’s easy because the DLL has the phrase “hook” in its name, which is something that certainly stands out!

A different way to identify the hooking DLL is to compare the list of loaded DLLs with and without the security solution active. To simulate this we run begin.exe twice – once with and once without the AChook.dll. To list the DLLs as a text we can use “listdlls”:

Output of listdlls against the begin.exe process.
Output of listdlls against the begin.exe process.

First we need to identify which DLL was injected into a process. We start by running listdlls against the just started begin.exe process and saving the output:

listdlls begin.exe > before

Then we inject AChook.dll using Process Hacker and save listdlls’s output again:

listdlls begin.exe > after

Next, we compare those two output files using “gvim” (of course any other text editor can be used).

Using gvim to compare both outputs.
Using gvim to compare both outputs.

As we can see below, a new DLL AChook.dll was added:

Diff of both lists of loaded DLLs in the begin.exe process.
Diff of both lists of loaded DLLs in the begin.exe process.

Alright. So far we determined that a DLL was injected to the process. At this point we could search the DLL on disk to see to if it belongs to your target security solution. In our case we created it ourselves though, so we’re not going to do that.

The DLL is suspicious because its name contains the phrase “hook”. However we want to gain more confidence that it really hooks anything.

When you are examining a security solution it’s always a good idea to read its documentation. The product that I was analysing had specifically mentioned that it uses MS Detours hooks to function. However, it did not mention anything regarding the application control implemented in kernel space and also did not mention which DLL it used for hooking.

Unfortunately there is no single (special) Windows API that would do the hooking. Instead it uses multiple APIs to do its job. I wanted to find a rare API or a sequence of APIs that I could use as some sort of signature. I found one API that is quite special and rarely used (unless you want to do hooking): “FlushInstructionCache”.


As the documentation says:

“Applications should call FlushInstructionCache if they generate or modify code in memory. The CPU cannot detect the change, and may execute the old code it cached.”

So if the MS Detours code wants its new jump instruction to be executed it needs to call FlushInstructionCache API. In summary what MS Detours needs to do when installing the hook is to:

  • Allocate memory for the trampoline function;
  • Change the access of the code of the target function to make it writable;
  • Copy the instructions from the beginning of the target function (the ones that it’s going to replace) to previously allocated space; and make changes there so that the trampoline function ends up executing your code;
  • Replace the beginning of the target function with a jump instruction to trampoline function;
  • Change the access of the code of the target function back to the original access;
  • Flush the instruction cache.

You can find the FlushInstructionCache function in the imports of AChook.dll as can be seen in IDA:

IDA displaying the PE imports of begin.exe.
IDA displaying the PE imports of begin.exe.

Or you can use “dumpbin” to do the same:

Finding the FlushInstructionCache PE import in begin.exe using dumpbin.
Finding the FlushInstructionCache PE import in begin.exe using dumpbin.

At this point we have a very suspicious DLL and we want to determine which APIs it hooks and also restore them.


Since I was experimenting with dynamic binary instrumentation tools before, I knew that it is also possible to detect hooks by using Intel’s Pintools. It requires you to write a small program however. I won’t go into detail here, maybe this is a topic for another blogpost.

But in short Pintools enables you to split the code into blocks, something very similar to what IDA does. It also enables you to determine to which binary or DLL this code block belongs to.

Remember that MS detours installed a jmp instruction at the beginning of the target API which jumped to a newly allocated memory region. So if you see at the beginning of the API that a code block is executed that does not belong to the API’s DLL then this API is hooked. The drawback of this solution is that the hooked API needs to run in order to be detected. It also does not allow you to retrieve the original bytes of the hooked API for restoration.

More information about Pintools can be found here.

Let’s discuss something much simpler and more effective instead. Remember that MS Detours first changes the memory to be writable and then changes it back, let’s use that to our advantage.

We will use windbg for this. What we need to do is to:

  1. Start begin.exe
  2. Attach windbg to the begin.exe process.
  3. Set a breakpoint on loading of AChook.dll (sxe ld AChook.dll)
  4. Continue execution of begin.exe process (g)
  5. Inject AChook.dll into begin.exe process (Process Hacker)
  6. The breakpoint will hit.
  7. Set new breakpoint on VirtualProtect with a custom command to print first 5 instructions and continue execution. (bp KERNELBASE!VirtualProtect “u rcx L5;g” )
  8. Set output log file and continue execution (.logopen C:\BLOGPOST\OUTPUT.log ; g)
  9. The debugger will start hitting and continuing the breakpoints. After the output stops moving click the pause button on the debugger.
  10. Don’t click on the ok button of the message box. Close the log file. Collect and inspect the data in the log file. Remove a few – if any – false positives (.logclose).

The whole process might look like this:

Debugging the begin.exe process in windbg.
Debugging the begin.exe process in windbg.

The output above shows that when the breakpoint of the CreateProcessWStub and CreateProcessAStub are hit for the first time, they are not hooked yet: they don’t contain the jmp instruction at the beginning yet. However, the second time they are hit we can see a jmp instruction at the beginning, thus we can cunclude that they are hooked.

From this output we know that  CreateProcessW and  CreateProcessA were hooked. It also gives us the original bytes so we could restore the original functions if we wanted to.


Using the above output of windbg, we can restore the original functions with the following windbg commands:

eb KERNEL32!CreateProcessWStub 4c 8b dc 48 83 ec 58
eb KERNEL32!CreateProcessAStub 4c 8b dc 48 83 ec 58

The steps are easier this time:

  1. Run begin.exe
  2. Inject AChook.dll into it (using Process Hacker)
  3. Attach windbg to the begin.exe process
  4. Run the commands mentioned above and continue execution (eb … ; g)
  5. Click on the “OK” button of the message box to launch myapp.exe

And – voilà! – here is the result:

myapp.exe executed by begin.exe after restoring hooked functions.
myapp.exe executed by begin.exe after restoring hooked functions.


In this blogpost we have discussed what hooks are, how to identify a DLL that does the hooking, how to identify the hooks that it sets and also how to restore the original functions once the hooking DLL was loaded. Of course a proper security solution uses controls in kernel space to do application control, so it’s not possible for the application to just restore the original functions. Although there could be implementation mistakes in that as well, but that is a story for another time.

I hope you enjoyed.

About the author

Oliver, is a cyber security expert at NVISO. He has almost a decade and a half of IT experience of which half of it is in cyber security. Throughout his career he has obtained many useful skills and also certificates. He’s constantly exploring and looking for more knowledge. You can find Oliver on LinkedIn.