The Grandoreiro banking Trojan's return highlights a critical issue: attackers don't need zero-days when they can exploit your legitimate software. By using the Duplicate Files Finder application as a cover, threat actors execute malicious code through DLL side-loading while your endpoint tools see trusted executables running normally.
This checklist helps you assess whether your organization can detect and prevent DLL side-loading attacks before they compromise financial systems. These attacks exploit the trust relationship between legitimate applications and their supporting libraries.
Checklist Overview
This assessment evaluates your technical controls for detecting DLL side-loading, your software integrity verification processes, and your incident response capability when legitimate applications become attack vectors. Each item maps to specific detection capabilities rather than generic security postures.
The checklist focuses on preventive and detective controls that address the technique itself, not just the malware payload. You're validating that your environment can identify when a trusted executable loads an unexpected library, regardless of whether that library contains known malicious code.
Prerequisites
Before starting this assessment, confirm you have:
- Access to endpoint detection and response telemetry covering DLL load events, not just process execution logs
- Current software inventory including all applications that use external DLL dependencies
- Documentation of approved code-signing certificates and the authority to validate certificate chains
- Incident response runbooks that specifically address legitimate application compromise scenarios
If you lack telemetry on library loading events, your first action is implementing that visibility. You can't audit what you can't observe.
Detection and Prevention Controls
1. Application Whitelisting Validates Both Executables and Their DLL Dependencies
Check whether your application control solution verifies the integrity of dynamically loaded libraries, not just the primary executable. Review logs from the past 30 days for instances where approved executables loaded unsigned or unexpectedly signed DLLs.
Ensure your application control policy blocks execution when a whitelisted executable attempts to load a DLL that lacks valid code signing or originates from an unexpected path. Maintain separate hash values for both executables and their required libraries.
2. EDR Monitors for DLL Loads from Non-Standard Paths
Validate that your endpoint detection rules flag when trusted applications load libraries from user-writable directories (Downloads, Temp, AppData) rather than protected system locations. Test by placing a benign renamed DLL in a Downloads folder and attempting to load it through a legitimate application.
Ensure your EDR generates alerts when applications load DLLs from paths outside their installation directory or system32/syswow64. Security teams should receive these alerts within five minutes and correlate them with process lineage data.
3. Code-Signing Verification Extends to All Loaded Modules
Confirm your systems validate digital signatures for DLLs at load time, not just during installation. Check whether your environment enforces signature validation for libraries loaded by already-running processes.
Ensure Windows systems have User Account Control set to validate all code, and your GPO enforces signature requirements for kernel-mode and user-mode code. macOS systems should use Gatekeeper with no exceptions for unsigned code.
4. File Integrity Monitoring Covers Application Directories
Review your FIM configuration to ensure it monitors application installation directories for unexpected file creation or modification. Specifically check for alerts when new DLL files appear alongside legitimate executables.
Ensure your FIM solution alerts within 15 minutes when files matching *.dll patterns appear in monitored application directories. Alerts should include file hash, signing status, and parent process information.
5. Anti-Analysis Detection Capabilities Exist in Your Environment
Verify whether your security tools can identify when processes perform environment checks characteristic of sophisticated malware. Grandoreiro, for instance, checks for specific security-related processes, system uptime, memory configuration, and virtualization artifacts.
Ensure your behavioral analysis tools flag processes that enumerate running processes, check system resource configurations, or query for debugging/analysis tools within their first 60 seconds of execution. Maintain updated lists of enumeration patterns that indicate anti-analysis behavior.
6. DNS-over-HTTPS Traffic Undergoes Inspection
Confirm whether your network security tools can inspect or block DoH traffic that bypasses traditional DNS monitoring. Grandoreiro uses Google's DoH service to resolve C2 domains, evading DNS-based security controls.
Ensure your proxy or next-generation firewall either blocks DoH entirely or decrypts and inspects it. Maintain visibility into all DNS resolution regardless of protocol, and correlate DNS queries with process-level telemetry.
7. Geolocation-Based Access Controls Align with Business Requirements
Review whether your systems flag or block connections to geographic regions outside your normal business operations. Telemetry showed Grandoreiro activity concentrated in Mexico, Spain, Peru, and Argentina.
Ensure your network controls alert when internal systems initiate connections to countries where you have no business operations. Maintain a documented list of approved regions and review exceptions quarterly.
8. Incident Response Procedures Address Legitimate Application Compromise
Validate that your IR runbooks include specific steps for scenarios where trusted applications become attack vectors. Check whether your team knows how to identify all instances of a compromised application across the environment.
Ensure your runbooks include procedures for: identifying all systems running a specific application version, validating DLL integrity for that application fleet-wide, isolating affected systems without disrupting the legitimate application's function on clean systems, and restoring known-good application states.
Common Mistakes
Trusting executables without validating their dependencies. Your application whitelist approves the primary executable but doesn't verify the libraries it loads. Attackers rename malicious DLLs to match expected library names and place them in the application directory.
Monitoring process execution without tracking library loads. Your EDR logs show a legitimate application starting normally. You have no visibility into which DLLs that process loaded or from which paths.
Implementing detection without response capability. Your tools generate alerts for suspicious DLL loading, but your IR team lacks procedures for investigating legitimate applications as attack vectors. The alert sits in a queue while the attack progresses.
Focusing on payload signatures instead of technique indicators. Your antivirus scans the malicious DLL after it's loaded and executing. Detection based on file signatures arrives too late to prevent initial compromise.
Next Steps
Prioritize items 1, 2, and 4 if you scored poorly. These controls provide fundamental visibility into DLL side-loading attempts regardless of the specific malware family.
If you can't implement application whitelisting with DLL validation immediately, focus on EDR rules that flag DLL loads from user-writable paths. This detective control catches most side-loading attempts even without preventive enforcement.
Schedule a tabletop exercise where your IR team responds to a scenario where a widely deployed legitimate application loads a malicious library. Identify gaps in your investigation and containment procedures before facing an actual incident.
Review your software inventory quarterly to identify applications that use external DLL dependencies. For critical applications, maintain hash values for all required libraries and validate them during routine security assessments.
