Alert Investigation: ORG001-GOOGLE-1
EXECUTIVE SUMMARY
The "File Shared Externally" alert is a false positive caused by the rule misclassifying people_within_domain_with_link sharing as external. The actor, user1@example.com, is an HR/operations user who changed four "Interview Feedback" Google Docs from private to domain-link visibility — a sharing scope accessible only to example.com users. This is the second occurrence of an identical two-step recruiting workflow within 7 days (resume PDFs shared one day, corresponding interview feedback docs shared the next), with no external recipients involved. No action is required on this alert; the rule definition should be reviewed to exclude domain-scoped link sharing.
ALERT DETAILS
| ALERT ID | ORG001-GOOGLE-1(00000000-0000-0000-0000-00000000001) |
|---|---|
| ALERT TYPE | Activity Rule — File Shared Externally |
| PROVIDER | Google Security Center |
| CREATED AT | 2026-06-03T06:54:27Z |
| HOST | Google Drive (cloud) |
| USER | user1@example.com |
| SEVERITY | LOW |
| SOURCE IP | 198.51.100.23(India/Delhi,ASN 64500—Example ISP) |
| FILES AFFECTED | 4×Interview Feedback Google Docs(CandidateA,CandidateB,CandidateC,CandidateD) |
| VISIBILITY CHANGE | private→people_within_domain_with_link(example.com domain only) |
| MITRE | T1567—Exfiltration Over Web Service(ruled out) |
INVESTIGATION QUESTIONS
What files were shared and to whom — is this actually an external share?
No external sharing occurred — all four documents were set to domain-link visibility scoped to example.com users only.
4 Google Docs titled 'Interview Feedback - [Candidate Name]' changed from private to people_within_domain_with_link
Sharing method is link-based, restricted to example.com domain — no external email recipients
The alert rule fires on any non-private, non-internally-shared state, incorrectly classifying domain-link sharing as 'external'
All 4 events occurred in a ~2-minute burst (06:54–06:56Z), consistent with a batch workflow action
Is this sharing behavior consistent with the user's role and established patterns?
Yes — this is the second occurrence of an identical HR recruiting workflow within 7 days.
user1@example.com owns a corpus of HR files: hiring spreadsheets, candidate resume PDFs, interview feedback docs, salary sheets — consistent with an HR/operations role
Identical pattern on 2026-05-28: 5 Interview Feedback docs shared to domain-link for the same candidates whose resumes were shared the prior day (2026-05-27)
2026-06-03 alert event mirrors this exactly: 4 Interview Feedback docs shared for candidates whose resumes were shared on 2026-06-02
21 total CHANGE_DOCUMENT_VISIBILITY events in the 7-day window, all setting to people_within_domain_with_link — no public or external shares
Google's own is_suspicious flag on the login: false
Is the source IP (198.51.100.23) suspicious — VPN, proxy, or threat-actor infrastructure?
ASN 64500 (Example ISP Pvt. Ltd.) — classified as ISP, not datacenter or hosting
All enrichment sources (IPAPI, IPRegistry, VirusTotal RDAP) return is_vpn=false, is_proxy=false, is_tor=false, is_datacenter=false
2 of 91 VirusTotal engines flagged malicious (GreyNoise, SOCRadar) — consistent with netblock-level noise, not targeted threat activity; 55 engines returned harmless
Login at 06:43:59Z (10 min before alert) from same IP — Google flagged is_suspicious: false
User's daily IPs vary across 7 days, all India-based — dynamic ISP addressing is consistent with this pattern
CONCLUSION
This alert is a false positive. The Google Activity Rule fires on CHANGE_DOCUMENT_VISIBILITY events where the new state is neither INTERNALLY_SHARED nor PRIVATE, but people_within_domain_with_link — which restricts access to example.com domain users only — is functionally internal sharing. The actor user1@example.com is an HR/operations user performing a documented, recurring recruiting workflow (share resume PDFs one day, share corresponding interview feedback docs the next), with the identical pattern confirmed on 2026-05-27/28. The source IP is a legitimate Indian ISP with no anonymization flags and Google's own suspicious-login detection returned false. No data was exposed externally and no follow-up action is required on this alert.
RECOMMENDED ACTIONS
MEDIUM Refine the 'File Shared Externally' rule to exclude domain-link sharing — Update the Google Security Center Activity Rule to add a condition excluding FILE_SHARING_METHOD = PEOPLE_WITHIN_DOMAIN_WITH_LINK, or scope it to only fire when sharing reaches external domains or public (anyone with link). This will eliminate recurring false positives from legitimate internal link-sharing workflows.
LOW Populate user1@example.com's directory title/department — The user's Google Workspace profile has no department or job title set, making role-based triage harder. Adding HR/Operations metadata would speed future investigations.
▸ Attack Timeline
| 2026-06-02(prior day) | user1@example.com shares 4 candidate resume PDFs(Candidate A,Candidate C,Candidate B,Candidate D)to people_within_domain_with_link—step1ofrecruitingworkflow |
|---|---|
| 2026-06-03T06:43:59Z | user1@example.com logs in from198.51.100.23(Delhi,India) — login_success,is_suspicious:false |
| 2026-06-03T06:54:26Z | InterviewFeedback-CandidateA changed from private→people_within_domain_with_link — alert triggered |
| 2026-06-03T06:55:22Z | InterviewFeedback-CandidateB changed from private→people_within_domain_with_link |
| 2026-06-03T06:55:57Z | InterviewFeedback-CandidateC changed from private→people_within_domain_with_link |
| 2026-06-03T06:56:34Z | InterviewFeedback-CandidateD changed from private→people_within_domain_with_link |
▸ Affected Accounts
user1@example.com (User One) — HR/Operations (inferred); Delegated Admin; 2SV enforced