Microsoft GSA Alerting
under review
C
Chris Piestrzeniewicz
Hi, we recently had an issue where Huntress flagged a possible unwanted connection coming in from Singapore.
In the Huntress system there was nothing at the time to indicate this was a legit connection, so an investigation was launched given the end user at the time advised he was in Australia. After reviewing in the Entra logs, it showed that this connection was done via Microsoft GSA and as such was indeed legit as the person accidently left their GSA client on.
I would like to suggest the following to handle situations such like this:
- (Preferred) Given Huntress has access to the audit logs etc, update the reporting in the identities to show that it was a VPN and its MS GSA.
- (Alternative) If GSA is considered trusted/low risk, then at the very least don't generate an escalation.
I raised this with the support team and was advised you only alert on "non-gated" VPNs (VPNs where there's no requirement to identify yourself, such as VPN's that are free or that offer a trial).. I can see how that cuts down on the possible false positives etc, but wouldn't it be better to classify all vpns and then perhaps have a standard template/profile applied at a client level which is "best practise" from Huntress and then let us decide what to alert on? Eg in the above scenario, Huntress might automatically tick GSA to be trusted but we might say "GSA isn't in use/permitted, we want to know if a connection is detected".
Rich Mozeleski
under review
Rich Mozeleski
closed
Hey Chris Piestrzeniewicz, I'm going to email you about this!
P
Phill Wade
Rich Mozeleski there are a few voters on this topic, so it would be good to know more about this as the topic has now been closed. While we don't currently have customers using GSA, we have several interested, and are likely to start testing and deploying soon. In the sign-in logs under the location tab, there is a "Through Global Secure Access" is that able to be used? As I understand it today, for GSA, there are no dedicated egresss points you can configure.
Rich Mozeleski
Phill Wade: I'll leave this open. We need to do some investigation into what these login events look like from the audit logs.
C
Chris Piestrzeniewicz
Just an update on this one, we also had alert/detection coming in from over seas. This time it was a Windows 365 cloud PC which was hosted in a customers M365 tenant which the end user was utilising to access company resources. Given how Huntress heavily promotes their relationship and integration with Microsoft, it would be great if false positives like this could be reduced or at least in the alert provide more context.
In this instance the email alert advised:
"Huntress detected one or more logins from India. This country is not the usage location provided by Microsoft nor was this country expected or unauthorized by an access rule when the login was observed. Action required: Let Huntress know if logins from India are unauthorized and should be reported as an incident or if this login was expected. Review the escalation for more details.
Note: This is NOT an incident report. If the Huntress SOC deems this activity malicious, you will receive a follow-on incident report, regardless of whether or not you resolve this escalation."
When using free/public IP lookup sites, they all point back to Microsoft Azure.
So perhaps instead if Huntress wanted to err on the side of caution and alert they could say:
"Huntress detected one or more logins from India. The IP address is associated with Microsoft Azure and was detected from a cloud PC with device ID XXXXXX-XXXXXX-XXXXXXX . Action required: Let Huntress know if logins from India or Microsoft Azure services are unauthorized and should be reported as an incident or if this login was expected. Review the escalation for more details.
Note: This is NOT an incident report. If the Huntress SOC deems this activity malicious, you will receive a follow-on incident report, regardless of whether or not you resolve this escalation."
Given Huntress have access to our logs/audit information in M365, I would assume its easy for the device ID to be pulled from the Activity Detail Sign ins -> Device info of the log(s).