SIEM: Syslog - ConnectWise ScreenConnect

Team: Managed Security Information and Event Management (SIEM)
Product: ConnectWise ScreenConnect
Environment: ScreenConnect Administration > Extensions; Huntress Platform
Summary: Collect ConnectWise ScreenConnect session activity and web login attempts in Huntress Managed SIEM, sent as syslog by ScreenConnect's Send Syslog Messages extension to a Huntress Agent syslog collector.

Vendor Information

Huntress provides third-party vendor instructions as a best effort to speed up onboarding. Vendor documentation and versions change often, so you might need to find the syslog documentation for your version of ScreenConnect. The Vendor Reference Links above point to the latest documentation at the time of writing.

In this Article

What Huntress Collects
Before You Begin
Enable a Syslog Collector in Huntress
Handing the Collector Details to Someone Else
Install the Send Syslog Messages Extension
Point the Extension at the Huntress Collector
What to Expect After Connecting
Searching ScreenConnect Logs in SIEM
Example Log Messages
What Is Not Collected
Troubleshooting

What Huntress Collects

The extension sends one syslog message per ScreenConnect event, in two families:

Huntress normalizes both families onto the shared SIEM fields, so a ScreenConnect login failure is searchable alongside failed logins from your other sources, and a ScreenConnect session is searchable by the technician, the remote machine, and both IP addresses. Every value the extension sends is also kept under the screenconnect. prefix, and the message text is kept in message.

When measured on a live account, session events accounted for more than 99% of the volume, and nearly all of them came from unattended Access sessions.

ScreenConnect client events from Windows endpoints. On accounts where Huntress has enabled Windows Application log collection, Huntress also collects the ScreenConnect client's own session start and end events, Windows events 100 and 101, from managed machines. The Huntress Agent on each endpoint collects these, not this extension, and they arrive with event.provider set to ScreenConnect. 

They share event.dataset: screenconnect.session with the extension's session events, so filter on event.provider Syslog-ScreenConnect to see the extension's events alone. Client events carry the client version, the instance fingerprint, and the relay server, but not the IP address, and they name the technician only when the client provides one. On one live account, fewer than 1 in 5 did.

Before You Begin

Before you begin, ensure you have:

• A ScreenConnect administrator with access to Administration > Extensions on a ScreenConnect server running version 22.4 or newer.
• A Huntress Agent that the ScreenConnect server can reach over UDP. It becomes the syslog collector. The extension sends UDP only, so a collector listening on TCP alone receives nothing.
• A Huntress account with the Huntress Managed SIEM entitlement, enabled on the organization the collector belongs to.

Plan for volume. Measured on a live account, five servers with many unattended machines sent about 1.5 million messages in their first two days.

Enable a Syslog Collector in Huntress

To enable a syslog collector, follow Collecting Syslog Sources to enable a syslog collector on a Huntress Agent. If you already have a collector the ScreenConnect server can reach, you can reuse it and skip to the next section.

1. Log in to Huntress and start the syslog setup as the guide describes.
2. When asked for a vendor, select Other / Generic.
3. Choose the Organization and the Endpoint that will act as the collector.
4. Under Transmission Method, select UDP and set the Listening Port. The default is 514.
5. On a Windows endpoint, add the inbound firewall rule shown by the wizard.

Warning: Select UDP. The Send Syslog Messages extension cannot send over TCP. A collector listening on TCP alone never receives a message, and neither side reports an error.

Install the Send Syslog Messages Extension

To install the extension:

1. In ScreenConnect, open Administration > Extensions.
2. Select Browse Extension Marketplace.
3. Search for "Send Syslog Messages," select it, then select "Install".

The extension then appears on your Extensions page.

Point the Extension at the Huntress Collector

To point the extension at the collector:

1. Open Administration > Extensions.
2. Find Send Syslog Messages and select Options > Edit Settings.
3. For Server, select Custom and enter the collector IP address.
4. For Port, select Custom and enter the collector UDP port. Leave it at the default if the collector listens on 514.
5. Select Save Settings.
6. Connect to any session to send a first message.

Warning: Leave the message text settings at their defaults. The extension lets you rewrite the text of each session message, such as SessionConnectedMessage, and Huntress identifies session activity by that default text. A rewritten message is still collected and searchable, but it gets no event.action or event.type, so searches and detections keyed on those fields miss it.

Note: Every event type is sent by default. Each has a Send...Message setting, such as SendLoginAttemptMessage; leave those set to true. An event type switched off is never sent and cannot be recovered later.

What to Expect After Connecting

The log source creates itself. Huntress creates a log source when the first message from the ScreenConnect server reaches the collector and recognizes it as ConnectWise ScreenConnect based on the message format. There is nothing to add by hand, and one log source appears per ScreenConnect server.

Events appear when ScreenConnect has something to report. The extension sends a message per event, not on a schedule. Connecting to a session or signing in to the web interface produces one.

The collection starts when the extension starts sending. ScreenConnect sends events as they happen, so activity from before the extension was configured is not collected.

Login attempts are the security signal. Every attempt to sign in to the ScreenConnect web interface includes the username, the visitor's IP address, the user agent, and the result. A ScreenConnect server reachable from the internet draws password-guessing traffic, and these events are how you see it: failures grouped by source.ip and user_agent.original separate a guessing tool from a technician who mistyped. When measured across 11 live accounts over seven days, every security event included a login result.

Logins that skip the login page have no referrer. A browser signing in from the ScreenConnect login page sends screenconnect.url_referrer; a script, an integration, or a password-guessing tool usually does not. When measured on live accounts, nearly every failed attempt during a large burst had no referrer, and so did a steady stream of successful logins from one account's automation. An empty referrer is worth a look, not proof of an attack.

A login waiting on a multi-factor authentication prompt has an unknown outcome. When the password is accepted, and ScreenConnect asks for a second factor, the login is not finished yet, so event.outcome is unknown rather than success.

Most session lines carry no action. Measured on a live account, 88% of session lines had no event.action, because they are event types Huntress does not name yet. They stay searchable through the screenconnect. fields and message.

Retention of collected events follows your normal SIEM retention. ScreenConnect's own audit history is governed by the ScreenConnect server; events Huntress has collected are governed by your Huntress retention.

Searching ScreenConnect Logs in SIEM

event.provider identifies the source. The normalized fields come first; every value the extension sends is also searchable under the screenconnect. prefix.

Note: user.name means different things in the two families. On a session event, it is the technician who connected; on a login attempt, it is whatever the visitor typed, which, on a failed attempt, may not be a real account. Filter on event.dataset when that matters.

Actions by ScreenConnect message:

Note: Any other session event, such as Files were sent, Files were dragged, or A session was deleted, keeps its text in message and its values under screenconnect., with no event.action. Search those by message.

Login outcome by ScreenConnect result, as observed on live accounts:

Note: Any other result ScreenConnect sends is recorded as failure, with ScreenConnect's own value kept in screenconnect.operation_result.

Example Query Builder rows. Each row is a field, an operator, and a value:

Note: The field box suggests the most common ECS fields and also accepts anything you type. Every screenconnect. field is searchable but absent from the suggestion list, so type those in full.

Example Log Messages

The examples below were produced by running synthesized ScreenConnect messages through Huntress's ScreenConnect parsing. The message shapes match those observed on a live account. Names, addresses, and IDs are placeholders.

A technician connecting to an unattended machine:

{
  "@timestamp": "2026-09-24T21:15:03.412Z",
  "event.provider": "Syslog-ScreenConnect",
  "event.module": "screenconnect",
  "event.dataset": "screenconnect.session",
  "event.action": "session-connected",
  "event.type": "start",
  "user.name": "Jane Technician",
  "source.ip": "198.51.100.7",
  "destination.ip": "192.0.2.10",
  "destination.address": "WKSTN-0042",
  "message": "A session was connected to",
  "screenconnect.sessionid": "6f1c2a4e-3b5d-4c8e-9a7f-0d2e4b6c8a10",
  "screenconnect.name": "WKSTN-0042",
  "screenconnect.host": "Jane Technician(198.51.100.7)",
  "screenconnect.guest": "Guest(192.0.2.10)",
  "screenconnect.is_public": "False",
  "screenconnect.type": "Access"
}

A failed login attempt against the web interface:

{
  "@timestamp": "2026-09-24T21:15:03.412Z",
  "event.provider": "Syslog-ScreenConnect",
  "event.module": "screenconnect",
  "event.dataset": "screenconnect.security",
  "event.action": "login-attempt",
  "event.category": "authentication",
  "event.outcome": "failure",
  "user.name": "admin",
  "source.ip": "203.0.113.25",
  "user_agent.original": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/140.0.0.0 Safari/537.36",
  "screenconnect.eventid": "0b7e4f2a-9c1d-4e3f-8a5b-6c7d8e9f0a1b",
  "screenconnect.time": "9/24/2026 9:15:03 PM",
  "screenconnect.network_address": "203.0.113.25",
  "screenconnect.operation_result": "CredentialsInvalid",
  "screenconnect.user_source": "InternalMembershipProvider",
  "screenconnect.url_referrer": "https://support.example.com/Login",
  "screenconnect.user_name": "admin"
}

A successful single sign-on login:

{
  "@timestamp": "2026-09-24T21:20:41.087Z",
  "event.provider": "Syslog-ScreenConnect",
  "event.module": "screenconnect",
  "event.dataset": "screenconnect.security",
  "event.action": "login-attempt",
  "event.category": "authentication",
  "event.outcome": "success",
  "user.name": "jane@example.com",
  "source.ip": "198.51.100.7",
  "user_agent.original": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/140.0.0.0 Safari/537.36",
  "screenconnect.eventid": "3c9d1e7b-2a4f-4b8c-9d0e-1f2a3b4c5d6e",
  "screenconnect.time": "9/24/2026 9:20:41 PM",
  "screenconnect.network_address": "198.51.100.7",
  "screenconnect.operation_result": "Success",
  "screenconnect.user_source": "Entra ID",
  "screenconnect.url_referrer": "https://support.example.com/Login",
  "screenconnect.user_name": "jane@example.com"
}

What Is Not Collected

• Activity from before the extension was configured. ScreenConnect sends events as they happen and does not replay history.
• Messages lost in transit. Syslog over UDP has no delivery confirmation or retry. A message dropped by the network, or sent while the collector endpoint is offline, is gone, and neither side reports it.
• Event types switched off in the extension. Any Send...Message setting set to false stops that event type at the ScreenConnect server.
• An action name for every event type. Only the events in the actions table get event.action. Rewritten message text loses it too. The events themselves are still collected.
• The second and later lines of a multi-line message, as part of the event. A command, script, or chat message that spans several lines arrives as a single record for the first line with all the ScreenConnect fields, and a separate record for each subsequent line. Those follow-on records carry the line's text, but no event.dataset and none of the screenconnect. fields, so a search on the session or the technician finds the first line only. When measured on live accounts, these follow-on lines accounted for up to 9% of a source's records on servers that run scripts through ScreenConnect.
• Fields from a tampered line. Machine names, chat messages, notes, and login-page input are typed by users and visitors. When that text imitates ScreenConnect's own fields, Huntress keeps the message but does not trust its values, so the line arrives without the normalized fields.
• Session recordings and screen content. The extension sends event records only.

Troubleshooting

No ScreenConnect log source ever appears. UDP fails silently, so neither side shows an error. Check, in order:

1. The collector listens on UDP, not only TCP, and on the same port the extension sends to.
2. The extension's Server and Port are set to Custom with the collector's values, and the settings were saved.
3. On a Windows collector, the inbound firewall rule from the collector wizard is in place.
4. Nothing between the ScreenConnect server and the collector blocks UDP on that port.
5. An event has happened since the extension was configured. Connect to a session to generate one.

The log source appears as a generic syslog source instead of ConnectWise ScreenConnect. Huntress recognizes ScreenConnect by the message format the extension sends. A syslog relay between the ScreenConnect server and the collector that rewrites messages breaks that recognition. Send directly from the ScreenConnect server to the collector.

Session events appear, but login attempts never do. Check that SendLoginAttemptMessage is true in the extension settings. Login attempts occur only when someone signs in to the web interface, so a server whose technicians stay signed in can go for a long time without one.

Events arrive but event.action is empty. Either the message text was rewritten in the extension settings, or the event type is not one Huntress has named yet. Restore the default message text, or search by message.

Records appear with only a line of script or chat text and no ScreenConnect fields. Those are the second and later lines of a multi-line command or chat message. Look for the first line, which carries the session and technician, at about the same time on the same log source.

A login shows event.outcome of unknown. ScreenConnect accepted the password and asked for a multi-factor authentication prompt, so screenconnect.operation_result reads OneTimePasswordRequired. A password that worked does not prove the login was completed.