Endpoints and infrastructure

Endpoint and infrastructure sources are host-based systems that generate security telemetry through an installed agent or supported host-level integration. These sources form the primary signal surface for Kaseya SIEM, enabling the managed SOC to detect, investigate, and respond to threats across user endpoints, servers, and infrastructure hosts.

Use this article to understand how real systems (endpoints and servers) participate in SIEM detection and investigation, not how agents are installed, deployed, or configured on individual machines.

This article explains:

  • What endpoint and infrastructure sources are

  • How endpoint and infrastructure sources become active

  • Where endpoints and servers appear in the UI

  • What types of telemetry these sources contribute, including default Windows Event Log monitoring.

  • How to tell, from the UI, that endpoint ingestion is working

What are endpoint and infrastructure sources?

Endpoint and infrastructure sources are systems that generate telemetry through an installed agent or host‑based integration.

These sources typically include:

  • User endpoints (workstations and laptops)

  • Servers (physical or virtual)

  • Infrastructure hosts running monitored workloads or services

Once active, these systems continuously generate security‑relevant activity that is analyzed and correlated with other data sources in Kaseya SIEM.

How endpoint and infrastructure sources become active

Endpoint and infrastructure sources become active in Kaseya SIEM after a host successfully reports telemetry. Unlike application‑ or integration‑based sources:

  • There is no Add Application workflow

  • There is no application‑level connection status

  • Visibility is established when the agent begins reporting

Association with an organization occurs as part of agent deployment or assignment. Once the endpoint reports in, it becomes an active data source within that organization.

For agent deployment methods, platform‑specific requirements, and onboarding procedures, see the endpoint and infrastructure deployment articles referenced from this section.

Where endpoint and infrastructure sources appear in the UI

Endpoint and infrastructure sources do not appear as configurable applications. Instead, their presence is reflected through alerts and investigation activity.

You will see endpoint and infrastructure sources in the following places:

  • Alert details: Host‑related context is included when endpoint or infrastructure activity contributes to an alert.

  • Analysis > Investigation results: Related activity across endpoints, network, and other data sources is correlated and displayed during investigation.

Endpoint visibility is activity‑driven rather than list‑driven. Systems become visible through the alerts and investigations they participate in, not through an organization‑level asset or application list.

How endpoint and infrastructure sources differ from other data sources

Different source types appear in different ways in the UI:

  • Endpoint and infrastructure sources appear through host activity in alerts and investigations.

  • Network and syslog sources appear in alerts and investigations through log‑based activity.

  • SaaS and cloud sources appear as applications and contribute context through alerts and investigations.

Endpoint and infrastructure sources are host‑centric, which is why they appear as systems and activity rather than as configurable applications.

What telemetry endpoint and infrastructure sources provide

Endpoint and infrastructure sources commonly contribute:

  • Process and execution activity

  • File and registry activity

  • Network connections originating from the host

  • Operating system events

  • Security‑relevant behavior observed on the system

This telemetry is evaluated alongside data from:

  • Network and syslog ingestion

  • SaaS and cloud sources

Together, these sources provide correlated visibility across endpoints, networks, and applications.

Endpoint detections may also include contextual metadata such as mapped attack techniques (TTPs) or operating system event identifiers derived from endpoint telemetry.

Windows Event IDs

Kaseya SIEM uses the same Windows Event Log monitoring set documented for the RocketCyber agent's Endpoint Event Log Monitoring capability. The following Windows Event IDs are collected by default:

Event ID Log Description
104 System Security log was cleared
1100 System Event logging was shut down
1102 Security Audit log was cleared

4625

Security

An account failed to log in

4649

Security

A replay attack was detected

4698

Security

A new scheduled task was created

4702

Security

A scheduled task was modified

4720

Security

Test user account created

4722

Security

A user account was enabled

4724

Security

An attempt was made to reset an account's password

4735

Security

Local Group Changed

4738

Security

User account password was changed

4740

Security

A user account was locked out

5142

Security

A network share object was added

5143

Security

A network share object was modified

5144

Security

A network share object was deleted

5145

Security

A network share object was checked by PsExec

7031

System

Service terminated unexpectedly

7034

System

Services Terminated Unexpectedly

7036

System

A defensive service was stopped

7040

System

Service was changed from auto start to disabled

64004

System

Windows File Protection was unable to restore file to its original version

NOTE  The monitored Event IDs represent the default Windows event monitoring set. Additional telemetry may be collected through integrated security products and endpoint detection platforms.

What you will see when endpoint ingestion is working

When endpoint and infrastructure ingestion is functioning correctly:

  • Alerts include host‑based activity and context

  • Endpoint activity appears in investigations

  • Process, network, and operating‑system context is attached to detections

There may not be a single “connected” indicator. Successful ingestion is confirmed through ongoing activity and visibility in alerts and investigations.

This article focuses on how endpoint and infrastructure sources behave in Kaseya SIEM after ingestion. Integration‑specific articles describe how individual tools are connected.

Relationship to other data source workflows

Endpoint and infrastructure sources fit into the broader ingestion lifecycle as follows:

  • Connecting data sources and integrations explains how sources are associated with organizations.

  • SaaS and cloud sources explain application‑level telemetry.

  • Network and syslog ingestion explains log‑based infrastructure data.

  • Configuring application behavior explains how ingested data is evaluated and tuned.

Each source type contributes a different layer of visibility.

Key takeaway

Endpoint and infrastructure sources are where real systems (endpoints and servers) become visible in Kaseya SIEM. They appear through alerts and investigations, not as configurable applications, and their presence is confirmed through ongoing activity.

Integration‑specific endpoint sources

Endpoint and infrastructure telemetry in Kaseya SIEM often originates from MSP‑managed security or monitoring tools that are connected as integrations and mapped to one or more organizations.

For tool‑specific setup instructions, credentials, and organization‑mapping behavior, see the following articles: