Managed SIEM

I want to create a custom alert/escalation based on SIEM queries, e.g, using SIEM queries to create an alert/escalation when specific accounts are logged into, without using the scheduled reports

CIPP Stores its logs in Azure Tables, they currently provide a SAS token that provides read only access to these logs. It would be awesome to export the action logs into Huntress SIEM.

Need more options for retention between 1 year and 7 years.

The current settings for non-reporting source management escalations cause issues with workstations that are offline for extended periods of time (after hours, weekends, etc.). It would be nice if there was a way to configure the duration separately for servers and workstations, along with a custom field rather than presents.

Detect Compromised IoT Devices, Residential Proxy Behavior, and Network Degradation Summary I would like to propose a Huntress detection capability focused on identifying unmanaged IoT devices that may be compromised, enrolled in botnets, used as residential proxies, or causing measurable network degradation. This is especially relevant after the FBI’s June 5, 2025 PSA on BADBOX 2.0, which warned that compromised internet-connected devices, including TV streaming devices, digital projectors, aftermarket vehicle infotainment systems, digital picture frames, and other IoT products, are being used to facilitate criminal activity. The FBI noted that these devices may be preloaded with malicious software or infected during setup through malicious applications and unofficial marketplaces. Problem Many organizations and home offices have unmanaged devices connected to trusted networks. These may include: * Streaming boxes * Mini PCs * Android-based media devices * Smart TVs * Cameras * Printers * Projectors * Digital signage * IoT gateways * OT-adjacent devices These devices often lack EDR coverage, are rarely patched, and may not be visible to security teams. The FBI warned that BADBOX 2.0 involves millions of infected devices and can provide access to compromised home networks through residential proxy services used for criminal activity. The FBI also listed unexplained or suspicious internet traffic, unofficial app marketplaces, disabled Google Play Protect, uncertified Android devices, and generic unlocked streaming devices as possible indicators. Proposed Detection Capability Huntress could create a SIEM/MDR detection use case that correlates unmanaged device behavior with network performance impact. Detection Signal 1: Suspicious IoT Device Profile Identify devices that match risky patterns: * Android-based streaming devices * Generic or unknown manufacturer * Unrecognized MAC vendor * Device not in approved asset inventory * New device appearing on the network * Device using unusual DNS patterns * Device communicating with proxy, VPN, or anonymization infrastructure * Device connecting to unusual countries or hosting providers Detection Signal 2: Abnormal Traffic Behavior Alert when an unmanaged device shows: * Large increase in outbound connections * Large increase in DNS queries * Excessive HTTP/HTTPS sessions * Repeated beaconing * High-volume traffic during idle periods * Communication with known malicious infrastructure * Residential proxy-like behavior * Sudden change in normal traffic baseline Detection Signal 3: Network Degradation Correlation Increase severity when suspicious device behavior aligns with: * Increased latency * Packet loss * Firewall session exhaustion * Switch interface errors * High uplink utilization * VPN instability * DNS performance issues * Endpoints becoming unreachable Example Alert Potential Compromised IoT Device or Residential Proxy Activity Observed: * Unknown Android streaming device joined the network * Device generated 38,000 outbound sessions in 20 minutes * DNS requests increased 1,800% above baseline * Traffic observed to proxy/VPN infrastructure * Network latency increased from 5ms to 140ms * Multiple endpoints reported connectivity failures Assessment: This behavior may indicate a compromised IoT device, botnet enrollment, residential proxy abuse, malware infection, or severe device misconfiguration. Recommended Response: * Isolate the device from the network * Validate device ownership and business purpose * Review DNS and firewall logs * Block suspicious destinations * Check for unofficial app marketplaces or uncertified Android builds * Remove or replace high-risk unmanaged device * Segment IoT devices from business systems Strategic Value for Huntress This feature would extend Huntress MDR beyond managed endpoints and into unmanaged device risk. It would help detect: * BADBOX-like IoT compromise * Residential proxy activity * Botnet behavior * Network flooding * Unauthorized streaming devices * Rogue devices on business networks * Compromised home-office devices impacting business access The goal is not to label a device as malicious based on brand or country of origin. The goal is to detect suspicious unmanaged-device behavior when it correlates with network impact and known botnet/proxy indicators.

Partners using NXLog to forward Windows Event Logs from air-gapped or segmented environments into Huntress SIEM receive generic/unparsed syslog instead of normalized Windows event data, limiting searchability and alert fidelity.

Currently, manually created orgs are logged but organizations created by deployment are not. Partner would like to include these possible events even if a user cannot be tied like with a note / category that it was created via deployment.

Custom alerting for the Huntress SIEM is becoming more of a compliance requirement for our customer's with industry compliance frameworks including CMMC and will likely become a hard requirement moving forward for other frameworks like HIPAA, PCI, CJIS, and other frameworks inside the United States along with other Countries and their respective compliance frameworks. If one of primary reason for not having Custom Alerting now is due SLA concerns by the Huntress SOC for them responding to custom alerts then what about other alternative options? Some of the other feedback posts for features like this one have been incorrectly marked Complete and do not appear to have the ability to re-open or confirm if they are still being followed by Huntress. https://feedback.huntress.com/siem/p/custom-alerts Alternative Options: Allow custom alerting to be created and include a forced acknowledgement flag for each alert rule that the Huntress SOC cannot promise the same SLA response times compared to standard Huntress SOC. Have Custom Alerts run as informational triggers to initially only alert Huntress customers and if important enough then they will reach out to SOC to reviewing further. (i.e, Custom Alert X is triggered which creates a new Huntress ticket using PSA/Email Integrations and the Huntress customer could then to run pre-defined ESQL/Scheduled Query before reaching out to SOC.)

I understand that internal Syslog collection is supported, but external Syslog collection is not yet available. It would be advantageous to have support for external Syslog collection to broaden the scope of log sources that can be integrated into Huntress SIEM.

We are starting to look at SIEM for clients and have our helpdesk techs look over AppLocker logs (as an example) but to give them a saved query they need to be Huntress Admin scoped - this is not what we are wanting to give them access to and would like to see Managed Queries setup for other roles as well.