Google Workspace: suspend or lock compromised accounts, not just sign them out
B
Byron Garcia
Based on conversations with Huntress support as well as our account manager it seems that ITDR for Google workspace currently revokes an active session once, but does not de-authenticate the account and does not perform more aggressive de authentication on subsequent logins.
The Cited concerns for this in documentation is that it may be too aggressive and can break some google workspace functionality.
I for one would find this acceptable so long as what breaks is documented and can be resolved by the admin.
I would much rather cleanup a broken config if it is feasible, as opposed to allow malicious actors to freely roam on re-entry.
Alternatively, if what breaks is not repairable or creates a massive support burden, we would like to at least see a far more aggressive session de-authentication for the user account, continuous, until the incident is resolved.
Perhaps a forced credential rotation as well to help keep those sessions de-authenticated.
If we can't block access completely via revoking access, I would hope it can be made far more difficult by other means.
I understand perhaps the huntress team and some other administrators may not share the wish for this level of protection, so perhaps this could be implemented in an opt-in and granular level
For example:
Default experience: Current
Opt-in settings/levels:
- Continue revoking sessions
- Force credential rotation
- Suspend and break integrations (The aggressive level Huntress suspects is too aggressive)
This way we can keep those actions separate if anyone was interested in a more aggressive de-auth but not rotating credentials and not breaking those application connections.
Some granular choice would ultimately be ideal in the matter.
And as with anything, we would prefer this to be on a per-organization level, because each org may have their own preference of how aggressive they want to have it as well.
Thanks for your consideration
Y
Yidel Steinfeld
+1 for forced password reset
M
Moshe Fleischman
Upvoting this. We just experienced this exact scenario in a real critical incident.
Huntress revoked the Google sign-in cookies, but because the password remained valid and the account stayed active, the threat actor was able to log right back in using the same credentials. Google did not prompt for MFA again on that browser/device.
At that point, the session revocation did not actually contain the account compromise.
I understand the concern around suspending an account and causing inbound email to bounce, but there needs to be a stronger containment option for confirmed compromises — whether that is temporary suspension, forced password reset, forced MFA reauthentication, or another mechanism.
For a critical account takeover, signing the attacker out should not be considered sufficient containment if they can immediately authenticate again
Rich Mozeleski
Merged in a post:
GWS Isolation/Suspension/Lockout
M
Matthew Nelms
Please add this feature, just like it is already working in M365. What good are session sign outs, if the attacker can just sign back in. User accounts should be allowed to be locked out/isolated/suspended, not just 'signed out'. May not continue my ITDR trial until this is working, as most of my clients are GWS. Would also be nice to see some more 'basic' security features available for GWS.
See huntress current available feature comparison: https://support.huntress.io/hc/en-us/articles/49300628099859-Understanding-the-Differences-Between-ITDR-for-Microsoft-365-and-ITDR-for-Google-Workspace
Rich Mozeleski
Merged in a post:
Google Workspace Identity Isolation
E
Elya Berger
I would like to have it for G Suite as well, so that an Identity (User, etc.) should be locked and isolated when suspicious activity has been detected, the same as in M365.
It would be helpful to have the option to turn it on if we want to, and if one of our tenants does not want to be isolated if an account is compromised, we can turn it off for them.
P
Peter Pawlus
"Amen! +1 for this. I don't want to wake up to an email that account is still active when likely compromised. I'd rather suspend and be safe rather than potentially have someone lurking around in an account for hours." I second what Bryan and Stephen said. I do incident response specifically for Google Workspace and I'm shocked you aren't suspending the accounts when there isn't the suspicion of a compromise. We'll suspend first, attempt out of band notification/confirmation with the user reset sign-in cookies and then continue to investigate/remediate OAuth access etc. It is rare on confirmed GWS ATO that they don't initially establish persistence after living off the land a while so minutes matter when help is hours away.
S
Stephen Cranfill
Amen! +1 for this. I don't want to wake up to an email that account is still active when likely compromised. I'd rather suspend and be safe rather than potentially have someone lurking around in an account for hours.
C
Calin Andrews
Huntress currently states the following regarding this:
"When an identity included in ITDR for Google Workspace is compromised, Huntress will Revoke Access to the account which will result in all currently signed in sessions being signed out.
Due to the nature of suspension steps within Google Workspace, we are currently not isolating further. Suspension within Google will disconnect more than just email services and may be considered excessively disruptive if performed without user knowledge."
I don't fully follow the logic behind that. I think revoking the session without disabling/suspending the user will achieve containment for the majority of compromise scenarios, but not necessarily in all cases.