Managed SIEM

Add native log parsing, field mapping, and normalized schema support for Zeek (formerly Bro) Network Security Monitoring telemetry in Huntress Managed SIEM. Why This Is Important: Zeek is an industry-standard open-source network monitoring tool heavily relied upon by MSPs and MSSPs for protocol-level network visibility (DNS, HTTP, SSL/TLS, TCP/UDP connection state, JA3 hashes, etc.). Currently, when Zeek JSON or Syslog events are forwarded to the Huntress Agent/SIEM, they are classified as Syslog-Generic or unparsed raw messages. While the raw logs remain searchable for manual investigations, the lack of native parsing prevents: Structured field mapping (e.g., source/destination IP, ports, query domains, user-agents, and SSL SNIs). Automated Huntress SIEM detection rules and anomaly signals from evaluating network layer events. Efficient log filtering and tenant-based customer segmentation across multi-tenant MSP environments. Requested Capabilities: Native Zeek Parsers: Pre-built parser rules for core Zeek log streams: conn.log (Network connection state & flow data) dns.log (DNS queries, record types, and responses) http.log (HTTP requests, hostnames, user-agents) ssl.log / x509.log (TLS handshake inspection, SNI, JA3/JA4 fingerprints) Field Mapping & Normalization: Automatically map Zeek JSON keys (id.orig_h, id.resp_h, id.orig_p, id.resp_p, query, host, server_name) into standard Huntress SIEM fields. Detection Engine Integration: Enable the Huntress SOC/Detection Engine to run automated signal correlations against structured network protocol telemetry. Impact on Partners: Native Zeek ingestion will allow MSPs to unify endpoint MDR with network-level visibility inside Huntress, reducing reliance on third-party vendor SOCs while enhancing threat-hunting speed and detection accuracy across managed environments.

SIEM integration for https://www.defensx.com/

Can the N-central feed be extended to N-Sight , its like the little brother of N-Central but only available as SAAS, no self hosted edition. Then us N-Sight users can get the logs ingested into Huntress

MCP (Model Context Protocol) adoption is rapidly expanding from interactive LLM sessions to autonomous agents and service accounts performing actions across security, infrastructure, SaaS, and customer environments. These workflows generate valuable audit telemetry, but there is currently no standardized way to ingest, interpret, and detect threats in MCP activity within Huntress SIEM. Desired Outcome Deliver a vendor-neutral approach for ingesting and interpreting MCP audit logs so Huntress can: Identify activity outside an entity’s authorized scope (users, agents, service accounts) Correlate MCP activity with the broader threat landscape (identity, endpoint, cloud, network) Enable actionable detections and automated response for suspicious or unauthorized behavior Key requirements: Normalized schema for MCP audit events Actor identification (user, autonomous agent, service account) MCP server/gateway/session/tool/target-platform context Source and target tenant/customer context for multi-tenant environments Requested action, privilege level, data sensitivity, execution result Authorization and RBAC context (allowed tools/actions) Support for successful, denied, and attempted activity—not just completed actions S3-based ingestion, with the ability for partners to normalize data into a Huntress-defined format

Proofpoint announced in their most recent webinar that they are working on an API to support SIEM reporting. They stated that it would be available as of July 2025. https://us2.proofpointessentials.com/api/v1/docs/index.php

Peplink firewalls

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

Please add an alert for any M365 password change, showing the user, timestamp, and initiator (self-service vs. admin). In passkey environments (like Windows Hello for Business), users typically don’t know or need their M365 passwords. That means any password change is a strong signal of risk — either a malicious actor attempting social engineering, or a user trying to bypass passwordless controls.

We'd like to label our Syslog Sources something other than "Syslog (Local)", if we have multiple sources configured it becomes tedious having to open each one and match IP addresses

Huntress should always escalate when a newly discovered device is not sending SIEM logs, regardless of the status of its other agents. After the device has established a history of successfully reporting, Huntress can use EDR and Microsoft Defender status to determine whether a future reporting gap requires escalation. When a device first checks in but does not send SIEM logs, Huntress should always create an escalation because this may indicate a missed deployment, misconfiguration, or allowlisting issue. The status of other agents should not suppress this initial alert. After a learning period, such as seven days of confirmed operation and successful SIEM reporting, Huntress should correlate future reporting gaps with the EDR and Defender agents on that same device. If either agent remains online while SIEM logs stop, Huntress should escalate because the device is active and the logging failure requires attention. If all available agents are offline, Huntress can reasonably classify the device as offline and suppress the missing-log escalation until it returns.