Managed ITDR

We recently received an escalation about a login through an unusual VPN service to an account at one of our clients. I wanted to share some feedback on the incident report and our follow-up with support, with the goal of helping improve reporting and user training. When we reviewed the reported IP addresses, we recognized them as belonging to data centers we regularly block due to brute-force attempts against that same client’s VPN. We disabled the affected account, revoked all sessions, and began investigating. Our investigation found that the attacker had successfully signed in from multiple IP addresses and registered an additional MFA method. We removed the malicious MFA method while retaining the user’s existing passkey. We also followed up with the user and verified that subsequent attempts by the attacker were failing. The incident report described a different sequence of events. It stated that the activity was detected because of the unusual VPN, but that the attacker had removed all MFA methods and subsequent attempts were blocked because no MFA methods remained. That did not match what we observed: the attacker added an MFA method, and our team removed it while leaving the legitimate user’s passkey in place. When we followed up with support, we were told that newly registered MFA methods are not expected to be reported and may or may not be included in the incident report. I also want to emphasize that Huntress’s unusual VPN alert is what prompted us to investigate in the first place. That alert gave us the opportunity to identify the compromised account and take action before this became a much larger incident, and we appreciate that. My feedback is focused on making the reporting that follows that valuable detection more accurate and useful. Clearly distinguishing the attacker’s actions from our remediation, along with explaining when newly registered MFA methods are monitored or included in reports, would help partners understand the incident and communicate it accurately to clients. This could also be a useful example for partner training: the initial alert successfully brought us into the investigation, while the differences in the final report highlight an opportunity to improve how the findings and response are documented.

It would be a good idea to deactivate any devices that were added in Entra during the attack, or at least include this step in the remediation plan, as these devices could provide persistence mechanisms for an attacker after the incident.

Providing the IP address causing a rule violation would be useful.

Add the ability to add multiple countries when creating location rules.

It seems that Huntress just wants this Entra Usage Location set so they can use it as a datapoint, setting it per user it tedious. MSP and IT also use JIT accounts which can create accounts on the fly. As an MSP, we are getting these alerts for every JIT account being created. For all our clients, we could simply just tell you (in settings) that USA is the only Usage Location, vs setting this on a per user basis. Above that, if there was a single user in say Japan, it would be better for us to set that usage location on their identity in Huntress, not in Entra.

Twice this week I have seen where hackers have gained a users password and the sign in logs in 365 show they tried it and it was successful, but failed to complete MFA so didn't get in. The sign ins were from new IPs, overseas and completely out of character. If the login succeeded we'd likely have received an alert from Huntress about an unusual country login at the least, but we don't seem to when the login didn't complete. Yet we definitely want to know about these ones, this means hackers have the users password even if they didn't actually get into 365 with it, and we still need to change it. We only knew about the two this week due to 365 itself alerting us through Lighthouse about a risky sign in. Surely firstly Huntress can see these logins just from the sign in logs and alert us, but secondly does it not monitor the 365 risky sign ins feature? I'd have thought that was easy and essential.

Hello, In a recent partner review meeting I mentioned a few friction points my team is experiencing in the rule creation. 1 - Bulk rules Many of our clients have dedicated teams that often travel together, to multiple destinations through the year. It would be great if we could create rules selecting multiple identities in the creation step where we currently are limited to a single identity or organization 2 -Multiple Travel Plans We often receive travel plans ahead of time, and sometimes these can be travel to the same country multiple times in the year. Huntress only allows creating one rule for a country per identity. We need the ability to create multiple with their own schedules as we receive and would like to input the info in bulk.

To help detect account compromises and locking out accounts that have been compromised rather than sending an escalation and leaving the account open to be abused by threat actors.

Rapid detection and response to emergent threat actor tactics

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