Managed ITDR

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.

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

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

Add an option to export CSV of Location and VPN rules marked as Expected, Unauthorized, etc, for reporting.

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.

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.

We need a better alerting system, or at least some kind of notification should you suddenly not get any data from client tenants.

## Problem Bringing a new M365 tenant under Managed ITDR is the first step of every partner-client relationship. Partners need that process to be fast, predictable, and visible — they need to see exactly where each tenant is in onboarding, get an accurate signal when something requires their attention, and minimize the time they spend manually walking each tenant through setup. Partners running ITDR across dozens or hundreds of tenants also need a single place to monitor onboarding progress without checking each integration individually. As Huntress expands Identity protection beyond ITDR, partners also need a simple path to add additional Identity products to a tenant they've already authorized — without restarting onboarding from scratch. ## What We're Doing About It We've rebuilt the ITDR onboarding flow with the partner experience at the center. Partners see clear status as each tenant moves through onboarding. Common errors are automatically corrected, and when partner action is required, we send a specific, actionable notification. The new onboarding flow also supports adding additional Identity products to an existing tenant as a one-click action. ## Impact The manual steps a partner walks through to onboard a tenant take roughly two minutes; the remaining onboarding work completes in the background. Real-time visibility into the status of every tenant being onboarded. Common onboarding errors are auto-resolved; the rest come with a clear, action-specific notification. Additional Identity products can be added without re-authorizing the entire tenant.

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.