The Challenge of Phishing from Legitimate Sources
A recent phishing campaign targeting State, Local, Tribal, and Territorial (SLTT) government networks highlighted a troubling issue: phishing emails were sent from legitimate Google infrastructure, passing all authentication checks. These emails assembled their payloads client-side, avoiding network detection. Security teams quickly realized their email gateways were giving these attacks a green light. This isn't just a compliance issue; it's a real-world problem that defenders must address.
The following questions reflect what practitioners need to know when legitimate services become attack vectors and traditional verification methods fail.
Q1: Blocking Phishing Emails with Valid Authentication
When phishing emails have valid DKIM signatures and pass SPF checks, blocking them becomes challenging. In this campaign, the sender was a legitimate Google account, so DKIM, SPF, and DMARC all passed. Your gateway saw a genuine Google Drive share notification.
Here's what you can do:
Focus on sender reputation at the account level. Threat actors used Google accounts under domains they controlled. If possible, flag Drive share notifications where the sharing account's domain doesn't match known business partners or common SaaS vendors.
Watch for subject line anomalies. The campaign used Unicode homoglyph substitution to evade keyword matching. Modern email security platforms can normalize Unicode before pattern matching. If yours doesn't, you're vulnerable to this tactic.
Analyze behavioral signals. A Google Drive share from a recently registered domain sent to multiple unrelated recipients is suspicious. This requires telemetry beyond the email itself, which isolated email gateways often lack.
Relying solely on sender authentication isn't enough. Authentication confirms the message's origin, not the sender's intent.
Q2: Beyond Endpoint Detection for Client-Side Assembly
The campaign used client-side JavaScript to fetch and assemble a dropper in the victim's browser, bypassing network-based payload inspection.
Here's what can still help:
DNS filtering. Although the lure page and staging buckets were on Google Cloud Storage, the command-and-control infrastructure used specific IP addresses. Blocking or alerting on connections to known VPS hosting providers can catch the C2 phase.
Browser isolation for external shares. Render external Google Drive shares in a remote browser session. This way, the dropper downloads into a disposable container, not the endpoint.
Enforce script execution policies. Require script signing and enforce Constrained Language Mode to prevent unsigned scripts from executing. This doesn't stop downloads but stops execution.
Endpoint Detection and Response is vital, but it should be your last line of defense. If your first detection is the RAT beaconing, you're already in incident response mode.
Q3: Communicating Risks of Blocking Google Drive
When the board asks why you can't just block Google Drive, explain the cost-benefit analysis. Blocking it organization-wide stops this attack vector but also halts legitimate collaboration.
Consider these alternatives:
Conditional access policies. Allow Drive shares only from approved domains. Everything else requires manual review or gets quarantined.
User behavior analytics. Alert on anomalous behavior, like a user suddenly downloading suspicious files from unfamiliar buckets.
Role-based segmentation. Apply stricter controls to high-risk users like finance and executives, while allowing standard policies for others.
The board's question is about risk management. Ensure you've quantified the risk and implemented proportional controls.
Q4: Managing WebSocket Traffic
The campaign used WebSocket for command and control. Blocking WebSocket traffic can disrupt legitimate business applications.
Here's how to manage it:
Enhance proxy inspection. Enable WebSocket frame inspection if your proxy supports it. Without this, you're blind to WebSocket threats.
Allowlist known-good WebSocket destinations. Explicitly allowlist endpoints for tools like Slack and Teams. Block or alert on other WebSocket connections, especially to residential ISPs and VPS providers.
Egress filtering by protocol and destination. Ensure your firewall rules don't allow unrestricted egress. Follow CIS Controls v8.1 to deny communications with known malicious IP addresses.
The campaign's shift to encrypted WebSocket shows it's evolving. If you're not analyzing metadata like destination and volume, you'll miss it.
Q5: Evaluating RMM Tools as Potential Threats
Remote Monitoring and Management (RMM) tools are used by both IT teams and threat actors. They provide persistent access and remote execution without triggering alerts.
Here's what to do:
Maintain an application inventory. Ensure RMM tools are authorized and procured through IT. This helps distinguish legitimate from malicious deployments.
Establish behavioral baselines. Monitor for unusual RMM activity, like endpoints suddenly contacting new RMM infrastructure.
Restrict RMM installation to privileged accounts. Prevent standard users from installing software. This breaks the attack chain.
Understand that UAC prompts can be bypassed. Don't rely on them as a sole control.
Q6: Detecting Compromise
To know if you're compromised, you need visibility similar to what the Center for Internet Security provides with Albert Network Monitoring.
Look for these indicators:
Outbound connections to specific IP blocks. Check logs for connections to Cloudzy AS14956 infrastructure.
Access to suspicious Google Cloud Storage buckets. Search for access to buckets with naming patterns used in the campaign.
PowerShell RAT artifacts. Look for specific file paths and PowerShell processes with encoded commands.
Unexpected RMM installations. Cross-reference installations with phishing email timestamps.
If you find these indicators, prioritize isolating finance systems and reviewing transactions, as the campaign aims for financial fraud.
Next Steps
The Center for Internet Security offers detailed indicators and detection signatures. If you're an MS-ISAC member, use Albert sensor data and MDBR feeds to automate detection.
For non-members, focus on enforcing CIS Controls v8.1 for inventory, secure configuration, access control, and network monitoring. The campaign exploited gaps in these areas, not zero-day techniques.
If your security stack can't answer key questions about external Google Drive shares or endpoint connections, you have a visibility problem. Address that first.
