SecPro #30: Stopping Cryptographic Failures, Qakbot at it Again
Hey,
I’ve been very excited to write today’s piece. It’s been eight months since we first started on the mission of sharing trusted and actionable bite-sized security content like Stopping Cryptographic Failures, tutorials, and useful resources for working professionals like yourself. With the SecPro, we’re leading the evolution of a new type of content vehicle that helps security professionals stay up to date and build skills to modernize security programs and improve your security posture.
SecPro issue #30 is here and I’m grateful to over 6000 smart, curious, and supportive members who have joined us since. I genuinely believe that as a community we’re tackling the most challenging cybersecurity problems and sharing actionable knowledge one issue at a time. Special shoutout to brilliant minds in cybersecurity including Packt authors and industry insiders who have contributed to this newsletter.
This Week: While OWASP’s new top 10 is still the water cooler talk of my home office, it seems that several high-profile vulnerabilities are coming to the forefront for all the big players. While Microsoft continues to bat away problems related to the HiveNightmare vulnerabilities found in June, a growing number of application development teams continue to face underlying issues. We also look at how the breakdown of cryptographic failures is becoming a bigger risk and an analysis of the notorious Qakbot malware campaign.
Today’s rundown:
-
-
- Qakbot at it Again: Attack Flow & Disinfection
- OWASP: Stopping Cryptographic Failures From Destroying Your App
- Tutorial: How to Generate a Payload using Msfvenom
- CVE-2021-24084: The Vulnerability Microsoft Just Won’t Patch
- Secret Knowledge: Building Your Security Arsenal
-
Let’s get to it.
Malware Detection & Analysis
Qakbot at it Again: Attack Flow & Disinfection
By Joe Anich
Stepping outside of their normal behaviors, the threat actors behind this Qackbot campaign have delved into an interesting attack leveraging the Craigslist email relay. Another detail that stands out in this campaign is the fact that they create new messages and images for each domain they register during the beginning stages of this attack. The tactic being used is Craigslist’s built-in email relay that is designed to anonymize communications between buyers and sellers to prevent personal information leaks. The figure below gives an example of the attack flow.
Craigslist attack flow
Qakbot email campaigns usually contain attachments or links that are malicious in nature whereas in this one, none of those are used. To avoid detection, the email contains just an embedded image along with a message indicating some sort of issue with the user posting. The email contains instructions to enter a URL into their browser to address the issue, but instead are greeted with a malicious, macro-enabled excel file that infects their machine. Below is an article by INKY that talks more about the attack itself with some additional details.
Fresh Phish: Urgency, Mail Relay Serve Phishers Well on Craigslist (inky.com)
The figure below is an example of the excel files that get downloaded in the campaign when a user goes to the URL listed in the email. If the user clicks on “Enable Content”, a macro will run that will run to infect the device with the Qakbot malware. One of the first things it will do is reach out to a command and control domain (C2) where the actual malware payload comes from. As it sits now, the C2 domains discovered are not accessible anymore. Nonetheless, administrators need to stay alert on these types of campaigns as they can be the beginning of something more damaging.
Malicious excel document
Once a device is infected, persistence is typically the next phase, which is done via scheduled tasks. From there it attempts to dump credentials, exfil data, or spread laterally in the environment via Windows Management Instrumentation (WMI). Worst case if not taken care of, cobalt strike implementation and ultimately ransomware becomes the endgame. Will cover more about Qakbot in a longer article in the coming weeks.
When it comes to protections for these types of attacks, we can look at some of the same protections that we have covered in the past. Since you know by now, I am a Microsoft person, let us talk about what the Microsoft security stack has to offer to help shrink that attack surface. First thing first, let us assume a few things, that you have Defender for Endpoint as well as Microsoft Defender Antivirus as your primary AV.
1. The first, and most applicable in this context is ensuring you have runtime macro scanning by AMSI (anti-malware scan interface). This helps reduce the malicious XLM macros which are still supported. The wonderful thing about this is that Defender for Endpoint can use the information that AMSI generates, by incorporating it into its learning models. To learn more about this, check out this article – XLM + AMSI: New runtime defense against Excel 4.0 macro malware – Microsoft Security Blog
2. Ensure cloud-delivered protection is on for Defender AV. This gives you Microsoft cloud-based learning protections to block a lot of the new variants of malware. Learn more here – Cloud protection and Microsoft Defender Antivirus | Microsoft Docs
3. Turn on Block at First sight (BaFS). Check out the article mentioned in the learn more section, but when you have the right settings enabled, Defender AV will query the cloud protection backend when it finds a suspicious but currently undetected file. During this, it will make a determination as to allow or block the file. Learn more here – Block at First Sight and Microsoft Defender Antivirus | Microsoft Docs
4. Enable Tamper Protection to help protect against malicious tampering of Defender AV settings to weaken the system. Learn more here – Protect security settings with tamper protection | Microsoft Docs
5. Enabling EDR Block mode, and yes, this can and should be enabled even if Defender AV is your primary AV. It gives you another layer of defense as it allows Defender AV to act automatically on post-breach EDR detections. Learn more here – Endpoint detection and response in block mode | Microsoft Docs
6. Enable Network Protection to help prevent applications or users from accessing malicious domains, or malicious content on said domains. Learn more here – Turn on network protection | Microsoft Docs
7. Configure Exchange Online to delete mail retroactively. This is also known as zero-hour, auto-purge, or ZAP. ZAP retroactively detects and neutralizes malicious phishing, spam, or malware messages that have already been delivered to mailboxes. Learn more here – Zero-hour purge | Microsoft Docs
8. Enable the following ASR rules
1. To help block the ransom and lateral movement stages:
- Block process creations originating from PsExec and WMI commands
- Block executable files from running unless they meet a prevalence, age, or trusted list criterion
- Use advanced protection against ransomware
- Block credential stealing from the Windows local security authority subsystem (lsass.exe)
2. To help block common techniques:
3. To help block common entry vectors:
That’s all for today everyone, hope you enjoyed this week’s article about what current threats are making their rounds as well as some protections everyone should be implemented to the best of their ability. Feel free to reach out to me on Twitter if you have questions. Joe (@trk_rdy) / Twitter
OWASP/Cryptography
Stopping Cryptographic Failures From Destroying Your App
By Austin Miller
OWASP’s updated Top 10 is still a hot talking point for us here at SecPro – that’s why we’re looking at A02:2021 – Cryptographic Failures this week. Cryptography is a complex subject that has evidently been neglected by security teams over the past few years. If you want to find out more about weak cryptographic algorithms, poor hashing practices, and how to avoid deprecated cryptographic functions, read on.
If you missed our coverage of A01:2021 – Broken Access Control, check out last week’s issue of the SecPro newsletter.
Stopping Cryptographic Failures: What are Cryptographic Failures?
You’d be forgiven for thinking that this category is a new one in OWASP’s Top 10 rundown. Sensitive Data Exposure ranked A3 on the 2017 list, but this risk has been renamed and pumped up to A2 to show the increased threat that OWASP and its readership have seen this year.
Unlike Sensitive Data Exposure (a symptom of the problem, not the problem itself), in 2021 cryptographic failures refers to any cryptographic measures that do not adequately protect sensitive data such as PII. OWASP’s list of what qualifies as failure is exhaustive, but highlights include:
1. Failure to encrypt the correct data
2. Failure to secure cryptographic keys and other management errors
3. Using outdated algorithms such as MD5 and SHA1 or deprecated cryptographic padding methods for encrypting data
4. Developing proprietary encryption methods which have not stood up to rigorous testing
Stopping Cryptographic Failures: Types of Sensitive Data Exposure
Understanding cryptographic practices mean understanding how sensitive data is lost. Before we can securely encrypt data, we must understand how the adversary hunts for weak security in modern data handling best practices.
Data at Rest
When data is stored and encrypted (granted that proper key management processes are in place, sensitive information is more difficult to access. Weak practices can lead to exposed data or encryption standards that seem more secure than they truly are.
Key OWASP concerns for data at rest:
1. CWE-261 – Weak Encoding for Password
2. CWE-759 – Use of a One-Way Hash without a Salt
3. CWE-916 – Use of Password Hash With Insufficient Computational Effort
A full list of CWEs can be found here.
Data in Transit
When data is moved from one destination to another, it can be more difficult to keep encryption standards in place without compromising the files that are sent. The adversary will possibly succeed in launching man-in-the-middle attacks against poorly optimized data in transit practices.
Key OWASP concerns for data in transit:
1. CWE-322 – Key Exchange without Entity Authentication
2. CWE-323 – Reusing a Nonce, Key Pair in Encryption
3. CWE-523 – Unprotected Transport of Credentials
A full list of CWEs can be found here.
How Is Sensitive Data Exposed Through Weak Cryptography?
We use encryption to keep threat actors away from important data, but implementing weak encryption practices gives them a predictable way to enter the network.
OWASP research has now led to 29 Common Weakness Enumerations (CWEs) that directly link to problems in cryptographic security. Poorly managed keys, deprecated hash functions, and poorly stored sensitive data are all among the top threats web applications developers fall prey to.
CWEs
Looking at mapped CWEs is one of the best ways to check the efficiency of your cryptographic methods.
CWE-296 – Improper Following of a Certificate’s Chain of Trust
Certificates on your network must be trustworthy. Self-signing certificates cause problems in application security because no one can trust a certificate that is only valid for one hop.
Best practices for certificate writing include:
1. Do not use self-signed certificates in your chain of trust, unless the certificate is the root
2. Require checks against all intermediate certificates that link back to the original root certificate
3. Implement checks to ensure that the root certificate stays uncompromised or you will find that it’s the root cause of your problems
CWE-321 – Use of Hard-coded Cryptographic Key
Linked more broadly with Even if a particularly clever dev thinks that hashing and salting the hard-coded password/session keys is a good idea, the fact remains that storing access information on a system is an easy way to get found out.
OWASP advises not hard-coding any information that could give the adversary a starting point. Even with the best defenses in the world, you are opening up your password/key to brute force attacks and other threats. As OWASP put it, [i]f hard-coded cryptographic keys are used, it is almost certain that malicious users will gain access through the account in question.
CWE-326 – Inadequate Encryption Strength
Using encryption methods that do not meet cryptographic requirements expected in modern security is an easy way to allow the adversary to attempt to access your systems. For example, using deprecated cryptographic algorithms will never deliver encryption that is sufficiently secure.
Use modern algorithms to secure your sensitive data. Using weaker cryptographic hash functions and algorithms such as SHA1 will mean that anyone who can download tools like sha1-bruteforce could break through your perimeter.
Stopping Cryptographic Failures: CWE-759 – Use of a One-Way Hash without a Salt
Not using a salt is lazy these days. There’s no reason not to include a salt with the hashes for your sensitive data, especially because many hashing tools automatically add them. What’s there to lose?
Remember that even if your encrypted data is stored with a salt hash, an adversary that has access to a large number of resources to draw upon (e.g. from cloud services) is still dangerous in this situation. Even the best key management practices and cryptographic randomness can still be exposed if threat actors have access to potentially limitless resources.
Stopping Cryptographic Failures: How Do I Protect Encrypted Data?
The never-ending concern for security professions – how can I know that encrypted data is actually secure? Best practices dictate that we should:
1. Use modern algorithms such as (at very least) AES-128
2. Store sensitive information as salted hashes where possible
3. Use multi-factor authentication for data that is business-critically sensitive
4. Implement healthy security practices across the organization to prevent data or the hashes of data from being exposed to the internet
Tutorial
How to Generate a Payload using Msfvenom
Binary payloads are executables that can be generated using the Msfvenom framework and once executed on a victim machine, would give us access to the system. This is useful functionality as sometimes; it can be much easier to simply social engineer a person to infect their system with a payload instead of finding a vulnerability that can be exploited.
There are mainly two types of binary payload that Msfvenom can generate: PE and ELF. PE stands for Portable Executable (PE) format and is used for executables, object code, DLLs, and others used in Windows operating systems. ELF stands for Executable and Linkable Format (formerly named Extensible Linking Format) and is used for executable files, object code, shared libraries, and core dumps on Unix and Unix-like i.e., Linux and other operating systems.
In this tutorial, we review the different types of reverse shells and discuss steps to generate individual payloads for every type of shell. Due to space constraints, this module is placed as a separate web page. Please click the button below to follow the complete tutorial online.
Exploits & Vulns
CVE-2021-24084: The Vulnerability Microsoft Just Won’t Patch
Do you remember the HiveNightmare / SeriousSAM bug for Windows from earlier this year? It worked by exploiting strange READ-access permissions to sensitive information hives that were granted to non-admin users. Because this vulnerability was so simple to exploit, you’d expect Microsoft to really batten down the hatches on these kinds of LPE exploits, right?
Well, Abdelhamid Naceri doesn’t think so. Having originally found the bug in October 2020, Abdelhamid has waited patiently before posting the exploit to his blog. Allowing arbitrary file disclosure (AFD) and local privilege escalation (LPE), it almost seems like Microsoft’s cyber-security team has learned its lesson from the HiveNightmare fallout.
How Was It Discovered?
Back in October 2020, security researcher Abdelhamid Naceri discovered that there was a serious fault in the Access work or school configuration settings.
When exporting the management log files, a collection of processes begins to work. Most of these processes are usually uninteresting, but the Device Management Enrollment Service (DMES) writes a series of files that should be admin access only.
By running a simple mounting script, a user can create a new location to save these files to even if they are not using a local administrator account.
How Does This Exploit Work?
Abdelhamid’s bug actually works in two ways. The initial exploit was discovered in October 2020 and allows non-admin users to access arbitrary files without proper permissions.
The second is much closer to the HiveNightmare exploit from earlier in the year, which raises real questions about how Microsoft approached the old local privilege escalation problem.
Part 1 – Arbitrary File Disclosure
The first exploit was found through the Access work or school window and following the files that were exported via the export management log option.
Following the operations that run through the Export function, Abdelhamid found that the Device Management Enrollment Service was the host. In this service, the Windows Mobile Device Management Service Diagnostics DLL (known as MdmDiagnostics.dll) started to save system files in a, particularly strange way.
The Exploit
Here’s where the magic happened.
When exporting the files to C:\Users\Public\Documents\MDMDiagnostics\MDMDiagReport.cab (a .CAB file is usually used to store important system files and/or drivers), a number of the operations were performed in C:\Windows\Temp. Especially interesting was:
- C:\Windows\Temp\DeviceHash_***.csv, where *** is the serial number and the device’s full hardware hash.
- C:\Windows\Temp\TpmHliInfo_Output.txt, including a lot of information about the device’s Trusted Platform Module (TPM)
This information is obviously already quite sensitive and not the kind of information you want a system leaking. But even more worryingly, Adbelharim was able to discover a further exploit from this same vulnerability which leads to even more chaos.
Part 2 – Local Privilege Escalation (ProfSvcLPE)
This exploit has a greater potential for damage because we can gain administrator rights instead of just bypassing the useful information security defenses. Somewhat concerningly, this bug was found due to a weakness in the official patch for Part 1 of this vulnerability.
The Patch
In the wake of the patch for CVE-2021-24084, Naceri found that the actual code hadn’t changed that much of the original code at all. In fact, only the CDirectoryRemover destructor (i.e. the tool for destroying directories) is removed.
Naceri goes on to explain that this doesn’t actually offer the system protection at all due to other snippets in the target system code.
Picture of the create directory process
The Exploit
Here, the vulnerability really starts to become clear again. Generally, this process would create a directory that would be locked from allowing parent rights because the junction (i.e. a directory that redirects a user to another directory) presumes that you won’t have access to both parent directories.
However, Naceri exploited the vulnerability to show that it has only locked a small number of these junctions. Although security has been raised since the previous exploit, it’s still possible for a user to circumvent the defenses by following the correct pathways.
For instance, Naceri noted that the path from C:\Users\Temp\Documents\My Pictures does not allow a non-admin end-user to access resources in ~\Temp\. Because of the Windows protections in the previous patch, this path is protected.
However, running along C:\Users\Temp\AppData\Local\History, the vulnerabilities still exist. The ~\Temp\AppData folder isn’t locked, meaning that the user can access and modify the files within. We’re back to square one! Now an attacker can turn the ~\Temp\AppData into a junction and use it as a jumping-off point for gaining local administrator rights and executing arbitrary code.
In effect, despite there being an official fix for Naceri’s findings, the vulnerability still remains. This isn’t the first time a cyber-security risk has been inadequately addressed by Microsoft, but this type of exploit seems particularly egregious – how have they identified a risk and implemented a patch that allows the same exploit to happen?
The ProfServLPE exploit has been shown to affect the following versions of Windows:
- Windows 10 v21H1 (32 & 64 bit) updated with November 2021 Updates
- Windows 10 v20H2 (32 & 64 bit) updated with November 2021 Updates
- Windows 10 v2004 (32 & 64 bit) updated with November 2021 Updates
- Windows 10 v1909 (32 & 64 bit) updated with November 2021 Updates
- Windows 10 v1903 (32 & 64 bit) updated with November 2021 Updates
- Windows 10 v1809 (32 & 64 bit) updated with May 2021 Updates
How Can I Defend Myself Until Microsoft Releases a Patch?
These exploits are particularly worrying because they are difficult to patch right now. The vulnerable functionality means that dealing with either of these issues effectively means waiting for Microsoft to find a better patch and instantly install it!
Best practices are the only meaningful change that worried Microsoft users can make at this point. Until effective system protection is in place, you can manage your cyber-security by following the best practices for the HiveNightmare exploit.
Deleting your shadow files is the only way to stop threat actors from accessing them. The easiest way to do that is to run the following command in the Command Prompt:
vssadmin delete shadows
Note: this will leave all systems that rely on shadow files exposed in the event of a serious mistake or ransomware. Be sure to create backups to reduce the need for shadow files.
Secret Knowledge: Building Your Security Arsenal
Discover useful security resources, cheatsheets, hacks, and open-source CLI/web tools.
New & Trending
- jtesta/ssh-audit – An SSH server & client auditing tool: banner, key exchange, encryption, mac, compression, compatibility, security, etc.
- aidansteele/cloudkey – Quickly clone an entire org/users repositories into one directory. Supports GitHub, GitLab, Bitbucket, and more.
- RUB-SysSec/nyx-net – A fast full-VM snapshot fuzzer for complex network-based targets. It can fuzz a wide range of targets spanning servers, clients, games, etc.
Network
- Etherate – is a Linux CLI-based Ethernet and MPLS traffic testing tool.
- aria2 – is a lightweight multi-protocol & multi-source command-line download utility.
- iptraf-ng – is a console-based network monitoring program for Linux that displays information about IP traffic.
System Diagnostics 🔍
- bpftrace – high-level tracing language for Linux eBPF.
- bashtop – Linux resource monitor written in pure Bash.
- Valgrind – is an instrumentation framework for building dynamic analysis tools.
The SecPro is a weekly security newsletter to help you stay sharp and upgrade your skills with trending threat insights, practical tutorials, hands-on labs, and useful resources. Build skills in as little as 10 minutes.
