Jump to content

Search the Community

Showing results for tags 'Malware'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • A Test Category
  • Immunet Information
    • Announcements
    • Support Documentation
    • FAQ
  • Immunet Community Discussions
    • Immunet General Forum
    • Ideas
    • Immunet Support (Issues/Defects)
    • False Positives
    • Malware Detections
    • Malware Removal
  • Immunet Local Communities
  • ClamAV For Windows Community
    • ClamAV For Windows General Forum


  • Knowledge Base
  • Installation
  • FAQs

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start








Found 3 results

  1. DLL side-loading is a popular technique used by threat actors to circumvent security solutions and trick the Windows operating system into executing malicious code on the target endpoint. In this post, we’ll explore how DLL side-loading works, why it’s an effective attack vector, and provide practical mitigation tips you can use to secure your systems against this growing threat. We’ll also look at why the Windows Downloads folder represents a particular risk, albeit one that can be easily mitigated. Dynamic Link Library, or DLL for short, is Microsoft’s implementation of the shared library concept. These libraries, which typically sport the .dll file extension, contain code and data that can be used by multiple programs at the same time. Unlike an EXE file, DLL files cannot be directly executed. Instead, an application will load DLL files when needed to carry out specific tasks that may not be a core function of the original program. This reduces the amount of code that needs to be written, simplifies maintenance, and saves disk space. Unfortunately, the way in which Windows searches for and loads DLLs can also be exploited by threat actors. When an application requires a DLL to run, Windows attempts to load the DLL from either a full path defined by the application or via a manifest file. A manifest is essentially a plain text file that contains information about the dependencies and configuration requirements of an application or component. Among other things, it specifies which DLLs should be loaded at runtime by the associated program. However, problems arise when the manifest file isn’t specific enough about the DLLs that the application should load or the file paths that the DLLs should be loaded from. Adversaries can exploit poorly configured manifest files by placing a malicious DLL with the same name as a legitimate DLL in a location where an application will load it before the DLL that should be loaded. The location for the malicious DLL can be determined because, unless otherwise specified, Windows uses a set search order for DLLs: 1. The directory from which the application loaded 2. The system directory 3. The 16-bit system directory 4. The Windows directory 5. The current working directory (CWD) 6. The directories that are listed in the PATH environment variable A successful side-loading attack may allow the attacker to execute code on the system, escalate privileges, or steal sensitive information. Why do threat actors use DLL side-loading? For threat actors, the main advantage of DLL side-loading revolves around detection evasion. Because the malicious code is executed within the context of a legitimate application, it can evade detection by some security mechanisms that are looking for suspicious activities or processes. This increases the chances of an attacker being able to carry out malicious activity without being detected. Ransomware incidents leveraging DLL side-loading. Over the years, a number of ransomware operators have used DLL side-loading to execute successful attacks. Some examples include: REvil: Adversaries exploited a side-loading vulnerability in MsMpEng.exe, a Microsoft digitally signed file that, ironically, runs Microsoft Malware Protection Engine. Operators used MsMpEng.exe to load a malicious DLL called mpsvc.dll, which contained the ransomware payload. Rorschach: Adversaries deployed Rorschach using DLL side-loading via the Cortex XDR Dump Service Tool – cy.exe – an Extended Detection and Response product from Palo Alto Networks. Babuk: Babuk operators successfully attacked a large manufacturing company by leveraging a side-loading vulnerability in NTSD.exe, an executable belonging to a legitimate Windows debugging tool. Mitigating DLL side-loading risks. Most DLL side-loading attacks require threat actors to have write access to a directory where the malicious binary is searched for and loaded from, and, therefore, mitigation begins with securing the perimeter through the use of all the regular cybersecurity best practices, including: Patch management: Keeping operating systems, applications, and security software up to date helps protect against known vulnerabilities and exploits that can be used for DLL side-loading attacks. Access restrictions: Restricting access to sensitive resources such as system directories, registry keys and administrative privileges can help prevent attackers from being able to place and execute malicious DLLs. Attack surface reduction: Disable unnecessary functionality such as file and printer sharing, remote access services and unused network ports to reduce the attack surface and limit the potential impact of a DLL side-loading attack. Safe downloads: Download and install software only from reputable sources, such as the official website of the vendor or a trusted third-party software repository. Cybersecurity training: Organizations should provide regular cybersecurity training with a particular emphasis on social engineering tactics that threat actors commonly use to gain initial access to a target system. Endpoint detection and response (EDR) tools can also play an important role in mitigating DLL side-loading attacks, particularly in large organizations with many endpoints. Emsisoft Endpoint Detection and Response provides continuous visibility of an organization’s endpoints, along with valuable insight into potential threats – including DLL side-loading. The Windows Downloads folder. As noted above, Windows searches for DLLs in a set order, and the first location to be checked is the folder from which an application is loaded. This means that when a new application is downloaded and run from within the Downloads folder, it may load any malicious DLL that is also in that folder. The Downloads folder is also the easiest folder for an attacker to place a malicious DLL in, a user simply needs to be tricked into downloading it. Fortunately, the risk of side-loading from the Downloads folder can be easily mitigated simply by ensuring the Downloads folder is kept empty except for the most recent download. Similarly, moving installers to the desktop prior to running them will also avoid any malicious DLL in the Downloads folder being loaded. What developers can do. Software developers represent the first line of defense against DLL side-loading attacks. The following practices may be useful in mitigating DLL side-loading: Specify the full path to the DLL: When loading a DLL, developers can specify the full path to the DLL instead of just the DLL name. This ensures that the correct DLL is loaded and prevents the system from searching for and loading a potentially malicious DLL. Use absolute paths: Developers should use absolute paths instead of relative paths when specifying the location of a DLL. Relative paths can be manipulated by attackers to trick the application into loading a malicious DLL from a different directory. Implement DLL signature verification: Developers can sign their DLLs using a digital signature and verify the signature before loading the DLL. While not infallible, this does provide a layer of assurance that the DLL is a legitimate component and has not been tampered with. Article by: Senan Conrad - cybersecurity expert
  2. Js.Downloader & Html.Exploite.CVE detected by Immunet but Quarantine Failed. Please can someone advise on how to remove these? GDY
  3. These .exe keep showing up in (C:\Windows) on Windows Server 2008 R2 Datacenter even after manual deletion. I think it's a miner, it also create .xml and .exe in (C:\Windows\System32\config\systemprofile\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5) and also in (C:\Windows\Fonts\Mysql) that I can't access.
  • Create New...