Major's Fried Chicken may have the best fried chicken recipe in the world, but what happens when that super secret recipe is fed to a generative AI chatbot?

Learning Objectives

We now support the configuration of a list of IP addresses that isolated endpoints can connect to. This advanced feature enables partners who do incident response regularly to work more efficiently by remotely investigating and remediating isolated hosts using their self-hosted RMM or other tooling. This feature supports static IP addresses only and will not work with cloud RMM or other tools which use dynamic IP addresses for agent connectivity.

See this support article for more information.

If you use Cloud RMM (or other tooling with dynamic IPs) and would like to see us add support for allow listing DNS addresses, please add your support to this feature request.

If you use ScreenConnect and aren't that you have updated to address the latest vulnerability, we strongly recommend against enabling this feature at this time.

We're excited to share that Signals Investigated are now accessible across the entire Huntress Platform. Data source specific detection views and autorun only investigations have been replaced with all encompassing investigated signal views. Signals Investigated clearly associate investigative actions taken by our 24x7 SOC to specific endpoints, Microsoft 365 identities and incident reports where applicable.

Take a look at this Knowledge Base article to understand more.

We are happy to announce an update to our PSA Integrations for ConnectWise, AutoTask, Kaseya BSM, and HaloPSA, this update provides a faster and easier way to map Huntress Organizations to the correct entities within your PSA solution. Please review our new Knowledge Base article on this process improvement.

Now that we've plowed through the end of year holidays, it's time to give another update on some of our progress on enhancing the MDR for Microsoft 365 product. Again, this does not encompass all of the work that the team has put into the product. These are simply the highlights.

When we identify a malicious inbox rule in Microsoft 365, we queue up a remediation task to disable or delete the rule. In some cases when we tried to delete the rule we would get back an error that the specified inbox rule didn't exist. This was an issue on our end where we weren't correctly identifying the unique rule ID in some cases. This has now been fixed and we're successfully remediating malicious inbox rules.

There are several steps required to configure Microsoft 365 to forward audit logs and any issue with any of the steps will cause the logs to never start or to stop even after they have been sending. We've identified some race conditions in the way we were executing the setup steps that could some times cause a failed setup and we're addressing those. We also beefed up our detection and monitoring so that we can identify when the necessary configuration is no longer working causing us to stop receiving logs. This only affects ~5% of our mapped tenants and that number keeps dropping as we work through the issues.

In the last report, we noted that we had started to include Spur.us VPN data to enrich the events we are receiving from Microsoft, and the results of the last 2 weeks have shown a significant increase in the number of successful detections of anomalous logins. This isn't the only indicator we're using to try and detect account takeovers, but is an indicator with a unique perspective. This serves to detect what a lot of folks generally refer to as impossible travel. Attackers generally use a VPN to disguise the source of their traffic so they are less likely to be shut down. Combining the use of a VPN with unique or uncommon geographic locations and other indicators allows us to better identify anomalies without flooding our SOC with false positives.

One of the more "interesting" things we've found while working with the event data from Microsoft is that in a lot of cases the identity of the user who initiated the action isn't clear unless you're a computer. For example, user login events (success and failure) have a field for the users UPN (unique identifier, usually their email address). This is the more human-friendly identifier for a user. Ideally you would be able to search for events with the users UPN and find all of the events. Unfortunately the reality is that this field is often not filled with a real UPN and instead has the value 'Not Available'. We don't know why this is the case, but it's how Microsoft is logging these events. The problem with this is that if you were to search for events using a users UPN, you wouldn't get all of their events because some aren't correctly associated.

Fortunately there is another field in these events that designates the users GUID (Globally Unique IDentifier) in the UUID format. These are not human-friendly. Based on this we've added some enrichment steps to our event processing that will identify when an event is not correctly associated to a user and will lookup the user based on their GUID so we can correctly identify the UPN, or human-friendly ID. This allows us to better identify all events for a given user using the human-friendly identifier. This is one of those capabilities that is necessary for accuracy, but not default functionality for SIEM solutions that are simply receiving logs from Microsoft 365.

We are happy to share that you can now manage your tasks in Huntress even easier with the newly designed Command Center homepage!

Follow along with this KB article to learn more.

As promised, this is the first of many updates on our progress addressing the issues we've identified and others have pointed out with our MDR for Microsoft 365 product. This list isn't exhaustive. There are other minor bug fixes and refactors happening, but we wanted to call some out since they are important.

We've partnered with Spur to enable us to enrich IP addresses associated with Microsoft 365 events. This allows us to identify the geographic location of IP addresses so that we can identify the location of the user who generated the event. Spur also provides us with information about the services provided by the IP address. This allows us to identify IP addresses that are part of VPN and anonymization networks, which is a good signal to our SOC analysts that they need to take a second look at what that login session has been doing.

We've been capturing this data for a little bit, but we've finally finished the work necessary to pass this data to our detection engine so that our Detection Engineering team can build detectors around suspicious activity and so that our SOC analysts can have better insight when investigating suspicious behavior. After deploying this to production we identified and reported to partners last week. We even had a partner post about our SOC detecting them working remotely and locking their account to be safe.

We found that when we were importing existing inbox rules for M365 users during Huntress onboarding, we were not generating alerts for our SOC analysts to report. It turns out that we had a bug that caused the events not to match the detectors, so we were not able to report on malicious inbox rules that existed we were deployed and started to receive the Microsoft 365 events from the audit log. After realizing this, we conducted a manual threat hunt to search for suspicious inbox rules we may have missed. In cases where a historical inbox rule detection occurred, an incident report was issued and a separate note with additional context was sent to the impacted partner.

Obviously this is a big problem and one that we addressed very quickly. We're also putting in place some testing to ensure that this can't happen again in the future. We've got a fairly robust monitoring and observability system in DataDog, we just need to expose some metrics around this so we can identify if it stops working in the future.

We found that in some cases, we were missing detections because the maximum number of hits an Elasticsearch rule was able to have was 100. This meant that if there were too many matches in a short time period, not all matches would be returned. This one was not obvious, because you don't know what you don't know, but we identified some events that we thought should have generated signals and did not and we've seen this issue with Elasticsearch before.

We updated the maximum number of hits for a query to 5,000 for now and we're continuing the work to move these detectors over to our new custom detection engine, where we don't have to worry about this limitation.

When you create an Entra Application (integration) to allow access to Microsoft 365 tenant data, you have to specify a list of permissions (scopes) for what you'll need to access. The downside to this is that if you ever need to expand that list of permissions in the future, everyone needs to re-authorize your application. This is not ideal since it requires user actions, and getting the attention of busy administrators to take care of this is challenging. A few months back we added new permissions to our Entra Application and while we thought we got everyone to re-authorize the application, we found that not everyone had the permissions our system needed to take the necessary remediations.

We've contacted the 71 affected partners and our support team is working with them to address the rules. This is a tricky one to say is fully solved because we try to only ask for the permissions we need, but if we expand what we're doing and need more permissions in the future, we'll have to ensure that everyone re-authorizes our application. In the future we'll put checks in place to automatically bug folks when we need them to re-authorize the application, and we'll also try to get as many of the permissions correct the first time.

I don't know how helpful listing the new detectors we're adding will be, but we've gotten a decent number of requests from folks to help them understand what types of things we're detecting, so here are a few new detectors we shipped:

Why do these detectors matter? Because they fixed much of the gap we had regarding detection efficacy. We have a few more key detectors we will be adding in the next couple of weeks.

While we identified some issues with some of our detectors and infrastructure, we were able to get these fixed and put tests in place to keep this from happening again. Nothing will be perfect the first time. Progress is the name of the game. We're going to keep iterating on what we have to make it better and to chip away at the never-ending list of TODOs.

-- Chris

In response to partner feedback we have updated the cadence of Credential Reporting from weekly to monthly to allow partners and their end customers more time to remediate findings. We also changed this feature from opt-out to opt-in for existing accounts. Account admins can opt-in within Account Settings and those who do not opt-in can still review and export identified credential files from the Process Insight Dashboard.

Huntress now detects and reports on end users accessing possible credential files that are being stored insecurely. unless an admin opts out in Account Settings. Learn more about what this feature has already identified for our partners here.

With this new feature, you have the ability to export Process Insights Data to Amazon S3 Buckets that are set to US East Region 1. Please reach out to Huntress support if you would like this enabled, and check out this KB for further information: https://support.huntress.io/hc/en-us/articles/22006480117395