Forward BeyondTrust Session and Audit Events to Your SIEM

TL;DR — You need two things working at the same time: a reachable receiver on your SIEM side and a BeyondTrust export target that matches that receiver’s protocol, port, and TLS expectations. The most common failure is sending TLS syslog to a plain UDP/TCP listener, or posting webhooks to a URL that redirects instead of returning 200/202 directly. Reading time: ~5 min

Goal

When you finish, BeyondTrust session and audit events will arrive in your SIEM in near real time through either syslog or HTTPS, and you will be able to prove delivery by generating a test event and seeing it indexed with the expected source host, timestamp, and event payload.

Prerequisites

• BeyondTrust admin access with permission to edit outbound integrations and event/audit export settings.
• Admin access to your SIEM or log collector.
• One reachable receiver endpoint, with protocol decided up front:
  • Syslog over UDP or TCP on port 514, or TLS syslog on port 6514, or
  • HTTPS webhook endpoint on port 443.
• A host you control to test connectivity from the collector side.
• openssl >= 3.0 — check with:

openssl version

• curl >= 8 — check with:

curl --version | head -n1

• If using syslog-ng: syslog-ng >= 4; if using rsyslog: rsyslog >= 8; if using Splunk HEC or another HTTP collector, the collector URL and token.
• The exact values to enter before you start: destination hostname/FQDN, port, protocol, TLS requirement, authentication token or client cert if applicable, and the list of BeyondTrust event categories you want exported.

Steps

Step 1: Stand up a receiver your SIEM already ingests

If your SIEM already has a syslog or HTTP collector, use that. If not, create one on a Linux host and forward from there.

For TLS syslog with syslog-ng, create /etc/syslog-ng/conf.d/beyondtrust.conf:

source s_beyondtrust_tls {
  network(
    ip("0.0.0.0")
    port(6514)
    transport("tls")
    tls(
      key-file("/etc/syslog-ng/certs/server.key")
      cert-file("/etc/syslog-ng/certs/server.crt")
      peer-verify(optional-untrusted)
    )
    flags(no-parse)
  );
};

destination d_beyondtrust_file {
  file("/var/log/beyondtrust-events.log");
};

log {
  source(s_beyondtrust_tls);
  destination(d_beyondtrust_file);
};

Then reload and check status:

sudo syslog-ng -s
sudo systemctl reload syslog-ng
sudo systemctl status syslog-ng --no-pager
sudo ss -ltnp | grep 6514

You should see LISTEN 0 128 0.0.0.0:6514 and Active: active (running).

If you want plain TCP syslog instead, change transport("tls") to transport("tcp") and use port 514 or another allowed port.

Step 2: Validate the receiver before touching BeyondTrust

Test the receiver locally first.

For TLS syslog:

openssl s_client -connect your-syslog.example.com:6514 -servername your-syslog.example.com -brief </dev/null

Expected output shape:

CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN = your-syslog.example.com
Verification: OK

For a webhook endpoint:

curl -i https://your-collector.example.com/events

Expected output shape for a healthy endpoint:

HTTP/1.1 200 OK
content-type: application/json

or:

HTTP/1.1 405 Method Not Allowed
allow: POST

A redirect is a bad sign for most event senders. Misconfigured output looks like:

HTTP/1.1 301 Moved Permanently
location: https://your-collector.example.com/events/

You should get a valid TLS handshake for syslog, or a non-redirect HTTP response from the exact final URL for webhooks.

Step 3: Open the network path from BeyondTrust to the receiver

On the receiver host, allow the exact port.

For Ubuntu with UFW and TLS syslog on 6514:

sudo ufw allow 6514/tcp
sudo ufw status numbered

For RHEL with firewalld:

sudo firewall-cmd --add-port=6514/tcp --permanent
sudo firewall-cmd --reload
sudo firewall-cmd --list-ports

If your SIEM is behind a cloud firewall or load balancer, add an inbound rule for the same port in your provider dashboard (for example: Security Group/Firewall Rules → Add inbound rule → TCP 6514 from the BeyondTrust appliance egress IPs). You should see the port listed as allowed in the local firewall and cloud firewall.

Step 4: Point BeyondTrust at the receiver

In the BeyondTrust admin interface, go to the outbound event export/integration area for your deployment and add a destination using the literal values from your receiver.

Use one of these exact value sets:

Then enable the event categories you actually need exported: session start, session end, session recording metadata, login/authentication events, admin changes, and audit events.

What you should see when this succeeds: the destination saves without validation errors, and any built-in connection test reports success or at least does not report DNS/TLS/connectivity failure.

Step 5: Generate a test event

Create a real event instead of waiting for production traffic.

Use one of these actions in BeyondTrust:

• Start and end a short test session with a non-production endpoint.
• Log in with a test admin account and then log out.
• Change a harmless admin setting and revert it.

If your collector is file-backed, watch the file live:

sudo tail -f /var/log/beyondtrust-events.log

Expected output shape for syslog:

<134>1 2026-08-05T14:22:31Z bt-appliance.example.com beyondtrust - - - {"event":"session_end","user":"test.admin","session_id":"abc123"}

You should see a new line within seconds of the test action.

Step 6: Forward from the collector into the SIEM if needed

If your receiver is only a relay, send the events onward.

For rsyslog forwarding all BeyondTrust-tagged lines to a remote SIEM over TCP, create /etc/rsyslog.d/60-beyondtrust-forward.conf:

if ($msg contains "beyondtrust" or $fromhost-ip == "YOUR_BEYONDTRUST_IP") then {
  action(type="omfwd" target="siem.example.com" port="514" protocol="tcp" template="RSYSLOG_SyslogProtocol23Format")
  stop
}

Reload:

sudo rsyslogd -N1
sudo systemctl restart rsyslog
sudo systemctl status rsyslog --no-pager

You should see rsyslogd: End of config validation run. Bye. and the service running.

Verify it works

Run the verification that matches your path.

For TLS syslog receiver health:

openssl s_client -connect your-syslog.example.com:6514 -servername your-syslog.example.com -brief </dev/null

Expected: CONNECTION ESTABLISHED and a valid certificate chain or the exact verification mode you intended.

For webhook health:

curl -i -X POST https://your-collector.example.com/events -H 'Content-Type: application/json' -H 'Authorization: Bearer YOUR_TOKEN' -d '{"source":"beyondtrust-test","event":"connectivity_check"}'

Expected output shape:

HTTP/1.1 200 OK

or:

HTTP/1.1 202 Accepted

For end-to-end delivery, generate one test session event and confirm all three facts in your SIEM search:

source host = bt-appliance.example.com
event type = session_start or session_end
timestamp = current time window

If your SIEM supports raw view, confirm the payload contains the expected session ID or username from the test action.

Common pitfalls

Sending TLS syslog to a plain TCP or UDP listener

Mistake: BeyondTrust is set to TLS syslog on 6514, but the receiver is listening on plain TCP 514 or UDP 514.

Symptom: connection tests fail, or you see TLS handshake errors like:

error:0A00010B:SSL routines::wrong version number

Fix: match both sides exactly: TCP + TLS + 6514 on both ends, or switch both to plain TCP/UDP.

Posting webhooks to a URL that redirects

Mistake: the configured URL is https://collector.example.com/events but the server redirects to /events/ or another hostname.

Symptom:

HTTP/1.1 301 Moved Permanently
location: https://collector.example.com/events/

Events never appear because many senders do not follow redirects for signed or authenticated POSTs.

Fix: configure the final URL in BeyondTrust exactly as returned in the location header, or remove the redirect on the collector.

Certificate name mismatch on TLS destinations

Mistake: the destination host is set to an IP address, but the certificate CN/SAN only contains the DNS name.

Symptom from test tools:

Verification error: hostname mismatch

Fix: use the certificate’s DNS name in the destination host field, or issue a certificate with the IP/DNS SANs you actually use.

Firewall opened on the wrong protocol

Mistake: 6514/udp is allowed, but the receiver is listening on 6514/tcp.

Symptom: ss -ltnp shows the service listening, but BeyondTrust cannot connect and no packets arrive in the app logs.

Fix: open 6514/tcp specifically and confirm with:

sudo ss -ltnp | grep 6514

SIEM parsing drops the events after receipt

Mistake: the collector receives the raw lines, but the SIEM parser expects CEF/LEEF/JSON and silently classifies them as unknown or discards fields.

Symptom: /var/log/beyondtrust-events.log contains fresh events, but the SIEM search shows only generic syslog or no extracted fields.

Fix: index the raw feed first, then add the correct parser or sourcetype mapping for the actual payload format BeyondTrust is sending.

Testing with no real event generated

Mistake: you save the destination and wait, but no session or audit action occurs.

Symptom: connectivity tests pass, yet nothing arrives in the SIEM.

Fix: start and end a short test session or perform a harmless admin login/logout immediately after enabling export.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.