Living off the Land in the Cloud: REDCap Breaches & Gmail Rule Exfiltration
Saw the latest report regarding the China-linked APT targeting North American research networks. It’s a textbook supply chain + cloud abuse scenario. They established persistence via a backdoor on REDCap servers—ubiquitous in academia and medical sectors—and harvested credentials.
The exfil method is the real kicker. Instead of setting up obvious external forwarding (which triggers basic alerts), they abused Google Workspace rules to silently copy emails. By modifying the victims' own inbox filters, they siphoned off sensitive R&D and defense comms right under the admins' noses.
Defenders need to audit their environment for these "living off the land" cloud tactics. You can use the Gmail API to scan for suspicious filter criteria or forwarding actions that shouldn't be there.
Here is a Python snippet to help audit user filters for unexpected rules:
def audit_gmail_filters(service, user_id):
results = service.users().settings().filters().list(userId=user_id).execute()
filters = results.get('filter', [])
for f in filters:
# Check for forwarding actions or broad "hasTheWord" criteria often used in these attacks
if 'forwardTo' in f['action']:
print(f"[ALERT] Forwarding rule found: {f['id']}")
if 'hasTheWord' in f.get('criteria', {}):
print(f"[INFO] Keyword filter detected: {f['criteria']['hasTheWord']}")
Has anyone implemented automated monitoring for FILTERS_CREATE or FILTERS_UPDATE events in their SIEM? I'm curious if you're seeing this specific pattern outside of the research sector.
We started correlating LOGIN_SUCCESS events with GMAIL_SETTINGS_CHANGE events in our SIEM after seeing similar "loot the inbox" techniques.
Here is a basic KQL query we use in Sentinel to catch rule modifications occurring immediately after a login from a new IP:
GoogleWorkspaceActivity
| where EventName == "filter_creation" or EventName == "forwarding_address_create"
| join kind=inner (GoogleWorkspaceActivity | where EventName == "login_success") on ActorEmail
| project TimeGenerated, ActorEmail, EventName, IPAddress
It reduced our false positives significantly compared to just alerting on any rule change.
REDCap has always been a nightmare for patching because of the plugins. We treat it as an internet-facing hostile zone.
From a sysadmin perspective, the best defense against the Google Workspace rule abuse is strictly limiting who can actually create forwarding rules via the Admin Console. We disable the ability for standard users to create filters that forward mail externally, forcing them to request it through a ticket. It's a bit draconian, but it stops this exact data loss vector.
This reminds me of the OAuth abuse trends we saw last year. The attackers aren't breaking the encryption; they are just abusing the UI features.
In addition to the API script, you can check your Workspace logs via gam if you prefer command-line tools:
gam print users all fields
| gam process printbatch ~csv
| gam user ~user print filters
If you see filters involving `list-id` headers for defense contractors or medical journals, you might already be owned. The level of patience this group showed—hiding for a year—is terrifying.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access