The resurgence of the Grandoreiro banking Trojan through DLL side-loading reveals a fundamental problem: your security team might be making the same mistakes that allow legitimate software to become an attack vector. When threat actors abuse trusted applications to bypass endpoint detection and response tools, it's not just about better signatures. It's about flawed assumptions in how you deploy and monitor security controls.
Here's why these mistakes persist and what to fix.
Why These Mistakes Keep Happening
Security teams often assume that legitimate, signed executables are safe. This assumption fails when attackers exploit the Windows DLL search order to inject malicious code through trusted applications. Recent research on Grandoreiro's campaign shows attackers using Duplicate Files Finder, a legitimate utility, to load a malicious mingwm10.dll library. Your EDR sees a trusted executable, while the attacker gains code execution.
This isn't new, but it keeps working because teams treat application whitelisting and EDR deployment as one-time tasks rather than ongoing validation processes. You're defending against what malware looks like, not how it behaves once it's running under the cover of legitimate software.
Mistake 1: Trusting Signed Executables Without DLL Load Monitoring
Why it happens: Application whitelisting policies focus on executable signatures, not on what those executables load at runtime. You approve the parent process and assume everything it touches is safe.
The consequence: When Grandoreiro places a malicious DLL alongside a renamed legitimate executable, your whitelist sees the trusted binary and allows execution. The malicious DLL loads before Windows searches system directories, and your EDR never flags the initial access because the parent process is clean.
The fix: Implement DLL load monitoring as a separate control from executable whitelisting. Configure your EDR to log and alert on DLL loads from non-standard paths, particularly when a process loads libraries from its current working directory before checking system folders. For NIST Cybersecurity Framework (CSF) 2.0 implementations, this maps to the Detect function's anomaly detection requirements. In ISO/IEC 27001 terms, you're strengthening Annex A 8.16 by adding a specific technical control for library injection detection.
Mistake 2: Running EDR Without Anti-Analysis Countermeasures
Why it happens: You deploy endpoint protection and assume threat actors will trigger detections when they probe your environment. You don't account for malware that checks for your security stack before executing its payload.
The consequence: Grandoreiro checks for 49 processes linked to debuggers, network analysis tools, and EDR software before communicating with command-and-control infrastructure. If it detects your security tools, it terminates execution. You never see the attack in your logs because the malware refused to run in your instrumented environment.
The fix: Deploy deception controls that make your production endpoints look like analysis environments to trigger malware self-termination, while your actual analysis tools run in stealth mode. Use process name randomization for your EDR agents and avoid default installation paths that appear in public malware analysis reports. This strengthens NIST SP 800-53 SI-4 by adding a deceptive layer that increases detection coverage.
Mistake 3: Ignoring DNS-over-HTTPS in Network Monitoring
Why it happens: Your network security team monitors DNS queries through your internal resolvers, but you haven't accounted for applications and malware using DNS-over-HTTPS to bypass your visibility.
The consequence: Grandoreiro resolves its command-and-control domain using Google's DNS-over-HTTPS service, sending encrypted queries over HTTPS that your DNS monitoring can't inspect. The malware gets its C2 address without triggering any DNS-based threat intelligence feeds you've deployed.
The fix: Block outbound DNS-over-HTTPS to public resolvers at your firewall unless you have a specific business requirement for encrypted DNS. Force all DNS resolution through your internal resolvers where you maintain query logging and threat feed integration. If you must allow DNS-over-HTTPS for legitimate applications, implement it through a controlled proxy that logs queries before encryption. This control supports NIST Cybersecurity Framework (CSF) 2.0 2.0's Protect function and ISO/IEC 27001 Annex A 8.20 by ensuring you maintain visibility into name resolution activity.
Mistake 4: Treating Geolocation Checks as Low-Priority Indicators
Why it happens: When your SIEM flags geolocation anomalies, you triage them below authentication failures and malware detections. You see them as contextual information, not primary indicators of compromise.
The consequence: Grandoreiro uses geolocation checks to blacklist certain countries and validate that it's running in a target environment. The campaign shows 40% of detections in Mexico, 17% in Spain, 13% in Peru, and 10% in Argentina. If your organization operates outside these regions and you detect this malware, it means the attacker has specifically configured it to run in your geography, indicating targeted reconnaissance rather than opportunistic infection.
The fix: Correlate geolocation data from multiple sources in your detection logic. When malware performs geolocation checks, cross-reference the results with your organization's actual operating regions. A mismatch should trigger high-priority investigation because it indicates the malware has been customized for your environment. Configure your Computer Security Incident Response Team playbooks to treat geolocation validation as a targeting indicator, not just metadata.
Mistake 5: Assuming Law Enforcement Disruption Equals Permanent Threat Elimination
Why it happens: When authorities announce takedowns of malware infrastructure or arrest campaigns, security teams deprioritize those threats in favor of active, undisrupted operations.
The consequence: Grandoreiro was disrupted by a 2024 multinational law enforcement operation, but the malware has returned with updated tactics. Your threat intelligence feeds may have downgraded its priority after the disruption, leaving you unprepared for its resurgence with DLL side-loading techniques.
The fix: Maintain active detection rules for disrupted threats for at least 24 months after law enforcement action. Threat actors rebuild infrastructure, modify code, and resume operations. When you remove detection coverage based on disruption announcements rather than confirmed threat elimination, you create gaps that returning campaigns exploit. Update your threat intelligence program to track post-disruption activity and treat resurgent threats as high-priority because they indicate the attackers have adapted to previous defensive measures.
Prevention Checklist
- Enable DLL load monitoring in your EDR with alerts for non-system path loads
- Audit application whitelist policies to include library load validation, not just executable signatures
- Randomize EDR agent process names and installation paths to complicate anti-analysis checks
- Block DNS-over-HTTPS to public resolvers at network perimeter
- Configure SIEM to correlate geolocation checks with organizational operating regions
- Review threat intelligence retention policies to maintain coverage for disrupted threats
- Test incident response playbooks against DLL side-loading scenarios
- Document which legitimate applications in your environment use DLL loading from current working directories
- Establish baseline for normal library load behavior across critical systems
- Schedule quarterly reviews of security tool visibility gaps identified in post-incident analysis
By addressing these common mistakes, your team can better adapt to evolving threats and strengthen your defense strategies.
