Reverse Engineering SmokeLoader: An In-Depth Analysis (Part 3)
The previous blog entry covered how SmokeLoader uses various obfuscation techniques to slow reverse engineers down. We also identified yet another shellcode being allocated to a memory region, which we then dumped and analysed. In this blog entry, we’ll try to identify some of the key API functions the malware employs through dynamic API resolution to allocate memory, store shellcode, and deceive analysts. This third stage uses techniques similar to those used before – dynamic API resolution – but this time, the APIs are declared on the stack as their names and don’t go through API hashing. A number of APIs are executed with GetProcAddress for the malware to dynamically resolve functionality. These APIs are: LoadLibraryA(“Kerne32.dll”) GetProcAddress(“VirtualAlloc”) GetProcAddress(“VirtualProtect”) GetProcAddress(“VirtualFree”) GetProcAddress(“GetVersionExA”) GetProcAddress(“TerminateProcess”) GetProcAddress(“ExitProcess”) GetProcAddress(“SetErrorMode”) Then we came up against an issue. The malware only wants to run on a specific version of Windows – we think it was made for Server versions. The Windows API, GetVersionExW, has its return values compared to a very specific version. So when we run this program, it causes an exception as we weren't on the correct Windows version. To get around this for now, we had to set the ZF flag in x32dbg to jump over the code that caused the exception. This is necessary, or the memory address in EAX will cause an exception two lines later. Taking another look at the function, we found another jmp eax! We then performed the same process of setting a breakpoint, executing until that point, and then dumping the memory. Conclusion The third part of our SmokeLoader analysis explored dynamic API resolution, and we found another layer of shellcode in memory to dump. By this point, it was clear that SmokeLoader had multiple layers of shellcode inside it, with layers of obfuscation to slow down reverse engineers. During our analysis, we came across a number of these issues relating to control flow obfuscation. Trying to jump to certain instructions to identify shellcode gave us the EXCEPTION_ACCESS_VOILATION error. The final blog post of this series will discuss this exception more closely, describe how to defeat it and look at some indicators of compromise you can identify in the later stages of reverse engineering.New CTI Labs: Threat Actors: Salt Typhoon – SNAPPYBEE Campaign Analysis & Threat Actors: Salt Typhoon
Salt Typhoon has been a threat actor that has caused a lot of worry for defensive teams all over the world. They are a threat actor group which has been predominately targeting Telecommunication companies. They have been in the media a lot over the past few months for their hacks on telecommunication companies in the US.Immersive were finally able to get access to some of the malware samples, as more get released we shall cover more of the campaigns. Threat Actors: Salt Typhoon This lab takes the user through who Salt Typhoon are, what their techniques, tactics, and procedures are, and who they target. Discussing their previous campaigns in depth and why they are so feared as a group. Salt Typhoon: SNAPPYBEE Campaign Analysis Many of our customers want to learn how salt typhoons operate. This lab shows people how to start hunting for them inside a network, taking our users through the different stages, techniques, and tactics they use and how to identify them for detection. Why should our customers care? Salt Typhoon are a big threat to telecommunication companies around the world. Their main focus is to be in a network and perform cyber espionage without being detected. They largely operate inside networks without being detected for a long time, sometimes even months to a year. Our customers need to proactively understand what this threat is and how to start monitoring for them in their network. Who is it for? Incident responders SOC analyst CTI Analysts Threat Hunters Here is the link to the threat actor lab: https://immersivelabs.online/labs/threat-actors-salt-typhoon Here is the link to the campaign analysis lab: https://immersivelabs.online/v2/labs/salt-typhoon-campaign-analysisReverse Engineering SmokeLoader: An In-Depth Analysis (Stage 2)
This is the second part of a series of blog posts analyzing the SmokeLoader malware. It goes into detail on how we reverse-engineered it to identify its objectives and actions. The first part of this blog series looked at the malware’s contextual information and some of our initial analysis considerations. In this second part, we’ll continue where we left off by going deeper into the debugging and decompiling process to identify more shellcode and obfuscation techniques. As a reminder, we left off the previous post by identifying the first shellcode in memory, which was located at memory address 0x008A300. EAX pointed to this memory address, where deobfuscated instructions were provided. The execution was now at this location, meaning we had to dump the memory and load it into Ghidra for some static analysis. We dumped the whole heap allocation from here instead of starting at 0x2310. When we started analyzing it in Ghidra, we had to start at location 0x2310. The first thing that occurred was a CALL instruction. The second stage of this malware runs similarly to the first stage but employs some API hashing to obfuscate the API function calls that the malware makes. The malware ultimately allocates memory on the heap, places obfuscated data there, deobfuscates it, and then calls it. The starting function of the shellcode resembles a similar structure to the main() of the parent stage malware. We’ve changed some of the names of the functions and variables to help you understand these screenshots. The first function did the API hashing and called a nested function for the process of LoadLibraryA and GetProcAddress. Inside the function called FUN_00002448, you are presented with the following: The image above shows a function that performs the LoadLibraryA and GetProcAddress processes commonly used by malware. This is done for the following APIs: LoadLibraryA(“Kerne32.dll”) GetProcAddress(“GlobalAlloc”) GetProcAddress(“Sleep”) GetProcAddress(“VirtualAlloc”) GetProcAddress(“CreateTool32Snapshot”) GetProcAddress(“Module32First”) GetProcAddress(“CloseHandle”) These APIs indicate some of the malware’s behavior. But the most important here is VirtualAlloc. The size of the allocated location on the heap is important to note for later dumping of the third-stage shellcode. The second important function is the allocation on the heap and the deobfuscation. In the debugger, we set a breakpoint at the line (*local_8)(), which is the location of the return value from VirtualAlloc. This process is the same as the previous stage; we simply had to dump the memory from that location then load it into Ghidra for the next stage! This image shows the jump to the new shellcode location 0x02420000! Conclusion The second part of our SmokeLoader analysis identified another location in memory where shellcode is being allocated and stored. We also identified some obfuscation and XOR decryption being used throughout. Stay tuned for the next blog entry, where we’ll delve even deeper into this sample to identify some of the key API functions the malware employs to allocate memory, store shellcode, and deceive analysts.Reverse Engineering SmokeLoader: An In-Depth Analysis (Stage 1)
At our recent event, Operational CTI: Lessons from the Attacks that Didn't Target You, we shared that we would releasing reverse engineering blogs on SmokeLoader. Here is part 1! SmokeLoader is a malware strain that’s been seen in the wild since at least 2014. It’s a backdoor that can be expanded by adding modules. This versatility makes the malware a bit harder to signature, but it's common practice among malware like this. One notable aspect of SmokeLoader is its attempt to hide its C2 activity by generating requests from legitimate sites as well as domains that the attackers control. Understanding the modules used as add-ons to each build can provide insight around the malware strain and the attack’s objectives. This first blog entry covers the more contextual information around SmokeLoader, including the campaign associated with it. We’ll also cover how we set up our analysis environment, and the considerations we had when analysing the preliminary stages. The campaign The 7Zip campaign saw the exploitation of the CVE-2025-0411 vulnerability. Exploiting this vuln increased an attacker’s chances of successfully infiltrating a company’s workstations by bypassing the Mark of The Web (MoTW) security controls. (We created a lab on the 7Zip campaign. Check it out here.) Once bypassed, the SmokeLoader executable stopped Windows SmartScreen from opening a warning window to the user. This blog picks up where our webinar left off. We’ll cover the SmokeLoader executable and analyze it to show you how it executes itself – there are many layers! The malware we’ll analyze in this blog is the last stage in the Trend Micro report. You can also have a read of VirusTotal’s report here. Let’s get to it! This malware gets downloaded as part of the attack chain with the extension .pdf.exe. In some workstations, file extensions aren’t visible, so in this case, the malicious file looks like it ends with “.pdf”. This is a social engineering tactic that tricks the workstation user into double-clicking the malware, thinking it will open a PDF instead of actual malware. According to VirusTotal, SmokeLoader is a 32-bit executable written using Microsoft Visual Studio and is 249.50 KB in size. This is really useful information you can use to start understanding what sort of instructions and patterns can be added to the binary from the Visual Studio compiler. Analysis setup Don’t forget! As with any malware, it’s important to place it in a sandboxed environment when you analyze it. You don’t know what it’s going to do yet! When doing deep analysis, you’ll need to use a debugger and a disassembler or decompiler. Here, we’re using x32dbg and Ghidra – both incredibly powerful tools. We took the following steps when analyzing the malware: We looked at the decompiler to see what code was coming up and made a hypothesis of what the code was doing. We opened the malware in a debugger and executed the code we analyzed in Step 1, going no further than what we already knew. We replaced any variable names or information in the decompiler to provide further context to the code. We repeated Steps 1–3 until the malware acted on its objectives. Reverse engineering This malware deliberately has many stages to slow down reverse engineers’ analysis. It goes through multiple stages of shellcode extraction and execution, multiple dynamic API resolutions, memory page protection changes, and process injection. The first thing we did was find main(), where the malware author's code is written. Ghidra is really helpful for this! We found the entry point, followed __tmainCRTStartup, double-clicked it, and found the code pattern ___tmainCRTStartup ();. This will help when we start looking for main() in the debugger. We now knew that the main function was the one with 0x7c80 as the last four hex digits of the address. We used this information to set a nice breakpoint on main() in the debugger. This can be confusing when starting out on your reverse engineering journey, so check out our lab on finding main() here.Once we had a breakpoint set at main() in the debugger, we started investigating what happened from there in Ghidra. Two function calls happened: one is a longer function, and the other is a few instructions followed by jmp EAX. Given that EAX has a memory address populated by the data address DAT_00512C44, which is initialized elsewhere in the program, we guessed that there’s some deobfuscation of instructions somewhere, and the jump instruction takes the code to that location. We could have set a breakpoint at jmp EAX in the debugger and executed the code until then. However, some malicious activity might have occurred before the jmp call in the previous function, so it was worth investigating. The first function, shown below, had many do-while loops, meaning that the code will execute the loop at least once. However, we inspected the code inside the loops and found there wasn’t much going on. There was a check at a certain data address, DAT_00512DFC, and actions were taken based on that – though exactly what actions were taken is unclear, given that it doesn’t execute. When checking, we reviewed the memory location of DAT_00512DFC in the debugger and found that it didn’t hold anything meaningful to make those checks occur. This shows that this code is likely kept in the malware, regardless of whether it’s used or not, and will only execute if a certain type of build is created. Another thing to note is that the Windows APIs that get called didn’t really do much anyway, and currently didn’t indicate much malicious activity. Some of the strings in this function might have seemed useful, but if the code doesn’t execute instructions associated with them or doesn’t directly manipulate them, they’re useless to our investigation. So we skipped over the loops in the debugger by finding the instructions after the loop, setting a breakpoint, and running the program until it hits that breakpoint. The third lab in the Foundational Binary Dynamic Analysis collection covers this technique in more detail. Scrolling down, you can see a function that’s outside the if statements and do-while loops: This is FUN_00417440(void). Inside this function is a call to LocalAlloc where the size is stored in DAT_00512dfc and the memory address location is stored in DAT_00512c44. Keen-eyed investigators will notice DAT_00512C44 is the memory location of the jmp EAX in the second function called from main(). This proves that our hypothesis from the beginning was correct: This function sets up a memory location with instructions that get executed later. It’s important to keep track of the value stored in DAT_00512DFC from the debugger because it’ll determine the size of the memory dump we’ll be making later for the shellcode! Finally, when looking at the bottom of the large function, we found a number of function calls: LoadLibraryA was followed by two function calls. This is interesting because the majority of the time, LoadLibraryA in malware is followed by GetProcAddress (which happens to be what’s inside FUN_00417470). Weirdly, though, the return from LoadLibraryA("msimg32.dll") wasn’t used. GetProcAddress in the next function was simply called statically instead of dynamically, finding it with LoadLibraryA. In this function, VirtualProtect was called to change the heap memory to executable! This technique, and how to analyze it, is covered in detail in the fifth lab in the Foundational Dynamic Analysis collection. The function after that holds a lot of XOR and array manipulation, so we assumed this is deobfuscation. The location being written confirmed this, starting at the location of our heap, which was just changed to executable. This technique is also covered in the third lab of the Foundational Dynamic Analysis collection. The final function in the block simply added 0x2310 onto the heap starting address: ` if (iVar4== 0xd606b) FUN_00417460();` So, we learned that everything in the function has been pointless! Attackers do this deliberately to slow down reverse engineers. And it works, but it’s still crucial to take these steps so we can confirm it’s pointless, not just assume that it is. Finally, we set a breakpoint in the debugger at the jmp EAX instruction, ran the program, then dumped the memory. Conclusion This first blog post covered the SmokeLoader malware’s campaign details and some initial analysis considerations, including how to identify and dump the first layer of shellcode. This is just the beginning! Stay tuned for more SmokeLoader analysis, including a look at what anti-analysis and obfuscation techniques are employed.Understanding CVE-2023-49103: A Critical Vulnerability in ownCloud Graph API
ownCloud is a widely used open-source platform designed for file synchronization, sharing, and collaboration. It allows organizations to host their own cloud storage, ensuring data sovereignty and compliance with privacy regulations. Its flexibility and rich feature set have made it popular among enterprises and individual users alike. However, as with any software, vulnerabilities can emerge, and in late 2023, a critical security flaw – CVE-2023-49103 – was discovered in its Graph API application. This flaw could allow unauthorized access to sensitive configuration details, such as admin passwords, mail server credentials, and license keys. The risk is especially severe for organizations using ownCloud in containerized environments, where environment variables may be exposed. Let’s break down the vulnerability, its impact, and mitigation steps. Details of the vulnerability The vulnerability resides in the graphapi application of ownCloud. It leverages a third-party library file, GetPhpInfo.php, which calls the PHP phpinfo() function. This function, while commonly used for debugging, outputs detailed information about the server’s PHP configuration. In containerized deployments, environment variables – which often include sensitive information – are exposed, posing a severe security risk. Docker-based deployments of ownCloud are particularly susceptible, as Docker containers often rely on environment variables to pass sensitive information like database credentials and API keys during runtime. Attackers exploiting this vulnerability can use the phpinfo() output to capture these details, potentially compromising the entire containerized setup. Even disabling the graphapi app doesn’t fully mitigate the issue, as the vulnerable file remains accessible unless explicitly removed. Impact of CVE-2023-49103 When exploited, this vulnerability allows attackers to extract sensitive information without requiring authentication. The exposed data could include: ownCloud administrator passwords Mail server credentials Database credentials ownCloud license key Such information disclosures could lead to data breaches, unauthorized access to critical systems, and further exploitation of the organization’s infrastructure. Exploitation in the wild This vulnerability has been actively exploited, highlighting the urgency for remediation. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has added CVE-2023-49103 to its Known Exploited Vulnerabilities (KEV) Catalog, emphasizing the need for immediate action by affected organizations. Steps to mitigate the vulnerability If your organization uses ownCloud, the following steps are advised to mitigate the risk posed by CVE-2023-49103: Update the Graph API application Upgrade to version 0.3.1 or later of the graphapi app. The updated version removes the vulnerable GetPhpInfo.php file, addressing the root cause of the issue. Remove the vulnerable file If upgrading isn’t immediately possible, manually delete the file located at: owncloud/apps/graphapi/vendor/microsoft/microsoft-graph/tests/GetPhpInfo.php Disable the phpinfo() function Modify your PHP configuration to disable the phpinfo() function. This precaution reduces the risk of similar vulnerabilities in the future. Change all exposed credentials Immediately rotate any credentials that may have been exposed, including: Admin passwords Mail server logins Database credentials API and storage keys Secure Docker environments For Docker-based deployments, use secret management tools like Docker Secrets or HashiCorp Vault to handle sensitive data instead of relying on environment variables. Limit access to containerized services and ensure proper network segmentation. Regularly scan Docker images for vulnerabilities and keep them updated. Keep your ownCloud server updated Ensure your ownCloud instance is running the latest server version, as updates often include critical security patches. Proactive security measures While addressing CVE-2023-49103 is essential, organizations should adopt broader security measures to prevent similar risks in the future: Conduct regular security audits Routine assessments can identify vulnerabilities before they are exploited. Implement environment variable best practices Minimize sensitive data stored in environment variables and use secret management tools. Utilize web application firewalls (WAFs) WAFs can help block unauthorized access attempts. Train teams on security protocols Ensure your IT teams are aware of emerging threats and understand mitigation strategies. Recommended content The Immersive Labs catalog includes a lab dedicated to CVE-2023-49103. This lab provides a vulnerable version of ownCloud hosted within a vulnerable Docker container. This lab offers an in-depth understanding of the vulnerability and its associated exploit through practical, hands-on experience. You’ll exploit the vulnerable instance to gain access to sensitive information, allowing you unauthorized access to the system as a privileged user. Conclusion CVE-2023-49103 underscores the importance of proactive security measures in software deployment. For organizations leveraging ownCloud, this vulnerability serves as a reminder to maintain vigilance, regularly update systems, and adopt comprehensive security practices. By promptly addressing the issue and implementing the recommended mitigations, organizations can safeguard their sensitive data and reduce the likelihood of compromise. Share your thoughts If this vulnerability impacted your organization, what steps did you take to fix it, and what changes have you made to prevent future issues?Patch Tuesday February 2025
CVE-2025-21418 - 7.8 - Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability Top of the list for things to patch this month is a local privilege escalation that threat actors are actively exploiting in the wild. No information is provided on which threat actors or how they are using it, but what we do know is that an attacker exploiting this vulnerability will be able to gain SYSTEM-level permissions on the affected host. As this is a local exploit, it does mean that an attacker or malicious insider must already have access to the target machine, typically through a phishing attack, malicious document, or another remote code execution vulnerability. Despite its relatively low score of 7.8 compared to a Critical 9.8, local privilege escalation vulnerabilities are valuable to attackers as they allow them to disable security tooling, dump credentials, or move laterally across the network to exploit the increased access. CVE-2025-21377 - 6.5 - NTLM Hash Disclosure Spoofing Vulnerability Another CVE to patch sooner rather than later is a zero-day that was discovered and disclosed in December 2024, with Microsoft announcing at the time that patches would not be available until 2025. Tracked as CVE-2025-21377, this vulnerability allows a threat actor to steal a victim's NTLM credentials by sending them a malicious file. The user doesn't have to open or run the executable, but simply viewing the file in Explorer could be enough to trigger the vulnerability. This specific vulnerability is known as an NTLM relay or pass-the-hash attack, and threat actors love this style of attack as it allows them to impersonate users in the network. If an attacker can collect your NTLM hash, they effectively have the encoded version of your password and can log in to workstations, servers, or other Microsoft servers as if they had your username and password. Preventing outbound SMB traffic can help limit the exposure, as this is such a prevalent technique Microsoft has specific guidance available on their website on Mitigating Pass-the-Hash (PtH) attacks CVE-2025-21400 - 8.0 - Microsoft SharePoint Server Remote Code Execution Vulnerability Microsoft SharePoint is a web-based platform that integrates with Microsoft Office, used to store, organize, and share information from any device. Details around this remote code execution vulnerability in SharePoint suggest that an attacker needs to be authenticated to exploit it. Exploiting this vulnerability requires a client to connect to a malicious, attacker-controlled server, and with this access, an attacker could achieve code execution on the client. In a network-based attack, if the attacker has access to a client that belongs to the “Site Owners” group, meaning they have full control of the client system, they can write injectable code to send to the SharePoint server that amounts to code execution. CVE-2025-21408 - 8.8 - Microsoft Edge (Chromium-based) Remote Code Execution Vulnerability Microsoft Edge (Chromium-based) Remote Code Execution Vulnerability refers to a potential security issue that, if exploited, could allow an attacker to execute arbitrary code in the context of the current user. Vulnerabilities such as these are often attributed to the way Microsoft Edge (Chromium-based) handles objects in memory. In relation to this specific vulnerability, successful exploitation requires a victim user to click on a malicious link so that the attacker can initiate remote code execution (RCE) on Edge’s renderer process – which is part of a multi-process architecture that handles much of the code that runs on a webpage, including JavaScript, HTML, and CSS. The idea is that sites and sessions are isolated so the misbehavior of one site doesn’t affect another in the same browser session. An attacker could potentially do a number of things after exploiting this vulnerability, including injecting malicious scripts into the running browser session, exploiting cross-site-scripting (XSS) vulnerabilities, stealing credentials from browser sessions, or deploying script-based malware that can be used to gain access to the user's machine. Microsoft has released a patch for this vulnerability, which users are encouraged to download. CVE-2025-21391 - 7.1 - Windows Storage Elevation of Privilege Vulnerability In today’s Patch Tuesday release by Microsoft, we see two vulnerabilities listed as ‘exploited in the wild.’ One is a Windows Storage Elevation of Privilege Vulnerability, given the Common Vulnerabilities and Exposure ID number CVE-2025-21391. With a CVSS score of 7.1, the CVSS metrics outline that this vulnerability doesn't affect confidentiality, so no sensitive data can be accessed. However, it can severely affect data integrity and availability. The impact of this vulnerability is classified as an Escalation of Privilege, indicating that the successful exploitation could allow an attacker to assume higher privileges on the compromised system. However, Microsoft has outlined that if the attacker successfully exploited this vulnerability, they could only delete targeted files on a system. Microsoft has released patches to mitigate this vulnerability. It's recommended for administrators to apply these immediately. CVE-2025-21376 - 8.1 - Windows Lightweight Directory Access Protocol (LDAP) Remote Code Execution Vulnerability LDAP (Lightweight Directory Access Protocol) is a critical component of Windows environments, serving as the backbone for authentication, directory services, and centralized identity management. A recently disclosed critical vulnerability in Microsoft’s LDAP implementation poses a severe risk, allowing remote code execution due to a combination of race conditions, integer underflow, and heap-based buffer overflows. Exploiting this flaw requires an attacker to chain these exploits together by sending specially crafted requests to a vulnerable LDAP server, potentially gaining full control over the system. A compromise could lead to lateral movement, privilege escalation, and widespread network breaches because LDAP is integral to Active Directory, which underpins authentication and access control in enterprise environments. This vulnerability follows a history of LDAP-related exploits, such as privilege escalation flaws and buffer overflow attacks, reinforcing the importance of securing directory services. Organizations must prioritize patching and hardening LDAP configurations to mitigate exploitation risks and protect their Windows infrastructure from potential attacks. This vulnerability represents a serious security risk to systems running vulnerable Microsoft LDAP servers. Due to its high value, attackers will spend more time creating an exploit for this vulnerability, which is an echoed theory by Microsoft, as it has been stated that this vulnerability is more likely to be exploited. Administrators are strongly urged to promptly apply the available security patches and implement recommended mitigation steps to protect against exploitation. CVE-2025-21379 - 7.1 - DHCP Client Service Remote Code Execution Vulnerability The DHCP Client Service is a crucial component in Windows environments, responsible for dynamically assigning IP addresses and network configurations to devices. A newly identified critical vulnerability in this service allows for remote code execution due to a Use After Free flaw, which can lead to memory corruption and arbitrary code execution. While the attack complexity is high, exploitation requires the attacker to position themselves in the network path between the target and its requested resource, executing a machine-in-the-middle (MITM) attack to intercept or manipulate DHCP responses. Additionally, the attack vector is classified as adjacent, meaning the attacker must be on the same local network segment, such as a shared Wi-Fi or Ethernet switch, making remote exploitation over a WAN infeasible. While this brings the criticality of the vulnerability down, it is still feasible for attackers to want to put this in their attacker's toolkit, and given DHCP’s fundamental role in network connectivity, a successful attack could compromise endpoint security, facilitate lateral movement, and enable further network exploitation. This vulnerability underscores the importance of securing DHCP communications through network segmentation, encryption, and prompt patching to mitigate potential threats. CVE-2025-21381 - 7.8 - Microsoft Excel Remote Code Execution Vulnerability Microsoft Excel is a widely used productivity tool in enterprise environments, making vulnerabilities within it highly valuable for attackers, especially for phishing and malware distribution. A newly disclosed critical vulnerability, CVE-2025-21381, allows for remote code execution due to an Untrusted Pointer Dereference flaw. This flaw occurs when a program accesses a memory location using a pointer that has not been properly validated and can be attacker-controlled. It can lead to memory corruption and arbitrary code execution when processing maliciously crafted Excel files. Exploiting this vulnerability would enable an attacker to execute malicious code on a victim’s system simply by convincing them to open a compromised document. This method is often used in spear-phishing campaigns and malware distribution, such as Emotet and Dridex. Excel vulnerabilities are particularly dangerous because Excel macros and embedded scripts have historically been a significant attack vector for APT groups, ransomware operators, and financial fraud campaigns, often bypassing traditional security defenses. Given its widespread use in corporate environments, this vulnerability highlights the ongoing risk posed by weaponized office documents, reinforcing the need for patching, disabling macros by default, and implementing advanced email filtering to prevent exploitation.New CTI Lab: CVE-2025-0411 (7-ZIP MoTW bypass) – Defensive
The Zero Day Initiative (ZDI) team at Trend Micro identified the exploitation of a zero-day vulnerability in the 7-ZIP application dubbed CVE-2025-0411, which was used in a SmokeLoader malware campaign targeting eastern European entities. 7zip is used all over the world by individuals and organizations, so it's essential users understand this campaign. CVE-2025-0411 (7-ZIP MoTW bypass) – Defensive CVE-2025-0411 is a Mark-of-the-Web (MoTW) bypass vulnerability that exists within 7 ZIP installations with a version older than 24.09. This vulnerability allows attackers to bypass the MoTW protection mechanism employed by the Windows operating system, designed to warn users after downloading potentially malicious software. Bypassing MoTW for attackers increases the chances of successful phishing attempts, which is one of the largest ways attackers get into organizations. Due to MoTW being bypassed, users are not warned of potential malicious intent if they were to execute files. Because of this, attackers spend a lot of time trying to find different MoTW vulnerabilities and are often patched in Microsoft's patch Tuesdays due to their prevalence. Why should you care? Bypassing security controls is ideal for attackers. If their downloaded files do not get warned against by Windows, then the chances of successful attack chain execution is much higher! Therefore, we created a lab to identify what this attack process looks like for defensive teams and how to identify each stage. The lab teaches you what to look out for when this vulnerability is exploited and how campaigns have used it in the real world. Who is it for? Incident responders SOC analyst Malware reverse engineers CTI Analysts Threat Hunters Here is the link to the 7zip lab: https://immersivelabs.com/labs/cve-2025-0411-7-zip-motw-bypass-defensive Related Labs, designed to give you similar skills: https://immersivelabs.online/series/elasticsearch-threat-hunting-apt29/labs https://immersivelabs.online/series/introduction-to-elastic/labsNew CTI Labs: Zero-day Behaviour: PDF Samples & UAC-0063 Intrusion: SIEM Analysis
Based on the report released by NCSC's CTO, a number of important cyber security developments occurred throughout the past week. We have created two labs on what we thought were interesting parts of the report to align with what NCSC is seeing out in the wild. Zero-day Behaviour: PDF Samples PDFs are used by everyone, and a researcher has found that you can embed commands that will communicate out to attacker-controlled servers – depending on which PDF reader a company has, you can exfiltrate NTLM data to aid in further attacks. PDFs can be used to initial access an attack, such as sending a malicious one via email. Therefore, we have created a lab for defensive teams to analyze what these PDFs look like under the hood and how to identify this newly found behavior. UAC-0063 Intrusion: SIEM Analysis It has been observed that the threat group UAC-0063 has been sending malicious documents around the world, targeting Asia and Eastern Europe in their latest operation. Their aim is cyber espionage and to gather information about governments, NGOs, defense, and academia. With their malware dubbed HATVIBE, they have been seen to use legitimate diplomatic documents with their malicious code embedded inside them. The lab provides an analysis of the attack chain, where our customers will understand what happens when one of the malicious documents is clicked on and what detections can be put in place to detect the attack. Why should our customers care? These two labs are based on information that the NCSC has thought the industry needs to know. Understanding the updated attack techniques of threat groups and new ways to execute commands in PDFs is incredibly important because social engineering is still one of the highest methods of initial access. Therefore, our customers will be able to analyze both these threats to develop detections early or to gain familiarity with how these threats work. Who is it for? Incident responders SOC analyst Malware reverse engineers CTI Analysts Threat Hunters Here is the link to the PDF lab: https://immersivelabs.online/labs/zero-day-behaviour-pdf-samples Here is the link to the UAC-0063 lab: https://immersivelabs.online/labs/uac-0063-siem-analysis
