Follow up on the latest improvements and updates.


Today we update our ConnectWise, Autotask, Syncro, and HaloPSA integrations! We will now automatically have tickets update when a Remediation Plan is Approved or Rejected within the Huntress Dashboard, the following information will be parsed into the PSA Ticket:
  • This Report was Approved or Rejected
  • The steps of the Remediation Plan
  • Who clicked the Approve or Reject button
No additional configuration will be required to include this new functionality.
We’re excited to announce an update to the Huntress UI Dashboard with new icons on the lefthand navigation that streamline access to our core product offerings:
When selected, these icons will lead you to the associated service detail pages you have accessed in the past.
Additionally, you'll notice the reporting icon has been moved to the top navigation button for easier access, and the Partner Enablement icon is now accessible through the top right menu.
We are excited to announce that we have updated the Huntress Platform to highlight comments from our SOC Analysts on investigations they have conducted, even for cases that were reviewed and closed without further action. Analyst comments were previously included with our foothold-specific investigations, but were phased out of the UI design when we released the more all-encompassing Signals Investigated feature. We are now reintroducing this information to reinforce the human-centric management and support that Huntress has always provided.
You will now see the investigative comments and the analyst's first name for all signals investigated by the Huntress SOC.
Please note that this change does not affect the signals we have reported to you; it only applies to signals that did not warrant a report being sent, as they were found to be benign.
For more information, please take a look at our Support Doc
Ex-basketball superstar, Ricky the Rocket, knows how to run a sports memorabilia shop, but can Ricky rebound from bad password storage?
Learning Objectives:
  • Demonstrate best practices for storing passwords
  • Show the dangers of insecure password storage
  • Explore the benefits of a password manager
  • Recognize the risks involved with opening unsolicited email attachments
Huntress is thrilled to unveil the extension of our Managed EDR, now featuring a solution specially crafted to tackle the distinct issues associated with macOS systems. Our endpoint agent offers enhanced visibility and detection abilities specifically adapted to handle the complexities of macOS threats. This recent enhancement allows Huntress’ customers and partners to experience a high standard of protection for both Windows and macOS operating systems. For more information about how to add Managed EDR for macOS devices please see our Support Documentation or go to the agent download page within the Huntress Dashboard.
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
  • Demonstrate the importance of keeping trade secrets confidential
  • Recognize the risks associated with using consumer chatbots
  • Understand the importance of following generative AI policies
Use your self-hosted RMM and other tooling on isolated endpoints
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
completely certain
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.




MDR for Microsoft 365

MDR for Microsoft 365 Progress Report #2

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.
Fixed a bug that caused some inbox rule remediations to fail
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.
More fixes to ensure we're receiving logs from every mapped Microsoft 365 tenant
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.
Detection of account takeovers has improved as a result of our VPN detection efforts
In the last report, we noted that we had started to include 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.
Better mapping of events to Microsoft 365 users
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.
Load More