Integrating Keeper Security Event Logs with Wazuh SIEM

What You’ll NeedSection titled What%20You%u2019ll%20Need

To follow along with this integration, make sure you have these components ready:

• Keeper Enterprise account with Advanced Reporting & Alerts Module (ARAM) enabled
• Wazuh cluster 4.x or newer (I’m using 4.13.0 and using a cluster for redundancy and high-availability, but you can also use a single instance)
• A separate Linux VM for syslog-ng connected in a DMZ
• SSL/TLS certificates for secure syslog transmission
• Network connectivity between Keeper, the syslog-ng VM, and the Wazuh managers
• Administrator access to the Keeper Admin Console
• Ability to open firewall ports for syslog traffic

A note on the architectureSection titled A%20note%20on%20the%20architecture

In my setup, I deliberately placed syslog-ng on a separate VM rather than running it directly pushing the logs to the Wazuh Manager. Why? Because this VM will be exposed to the internet to receive logs from Keeper’s cloud service. By keeping it separate on a minimal, heavily monitored and restricted VM, I add an extra layer of security. If the syslog receiver is ever compromised, my Wazuh SIEM remains protected behind another network boundary. Think of it as a security buffer zone or DMZ specifically for log ingestion.

This approach follows the principle of defense in depth, even if an attacker compromises the internet-facing syslog-ng VM, they still need to breach the internal network to reach Wazuh, and they can’t tamper with historical logs already stored in Wazuh’s immutable archives.

Understanding the Data FlowSection titled Understanding%20the%20Data%20Flow

Before we start configuring things, let’s understand how data flows through our setup:

1. Keeper pushes audit events in near real-time via encrypted syslog on port 6514
2. syslog-ng receives and processes the connection
3. syslog-ng forwards the payload via an unencrypted connection to the Nginx load balancer which forwards it to one of the Wazuh Managers available
4. Wazuh Manager applies decoders and rules to generate alerts
5. Wazuh Indexer stores the data for searching and reporting
6. Wazuh Dashboard provides visualization and investigation capabilities

This architecture gives us security (TLS encryption and an isolated receiver), reliability (load balancing), and flexibility.

Security Consideration: While the connection between syslog-ng and Wazuh is unencrypted (due to Wazuh’s limitation), this is an acceptable risk in my setup because both systems are on an internal, isolated network. If your environment requires encryption throughout the entire path, consider:

• implementing IPSec for network-layer encryption on the management network
• deploying Wazuh agents with built-in encryption instead of direct syslog forwarding

Configuring the message pathSection titled Configuring%20the%20message%20path

1
/ip firewall nat
2
   add action=dst-nat \
3
   chain=dstnat \
4
   dst-port=6514 \
5
   protocol=tcp \
6
   to-addresses=10.x.x.x to-ports=6514

1
options {
2
    threaded(yes);
3
    chain_hostnames(no);
4
    stats_freq(0);
5
    mark_freq(0);
6
};
7

8
source s_tcp {
9
    network(
10
        port(6514)
11
        transport("tls")
12
        tls(
13
            key-file("/etc/syslog-ng/certs/keeper.root-security.eu.key")
14
            cert-file("/etc/syslog-ng/certs/keeper.root-security.eu.pem")
15
            peer-verify(no)
16
        )
17
        flags(no-parse)
18
        keep-alive(yes)
19
    );
20
};
21

22
destination d_wazuh {
23
    network(
24
        "wazuh.root-security.eu"
25
        port(514)
26
        transport("tcp")
27
    );
28
};
29

30
log {
31
    source(s_tcp);
32
    destination(d_wazuh);
33
};

1
systemctl restart syslog-ng

1
stream {
2
   // ... (agent and cluster upstreams config omitted)
3
   upstream wzmsyslog{
4
       hash $remote_addr consistent;
5

6
       server 10.x.x.1:514;
7
       server 10.x.x.2:514;
8
   }
9
   server {
10
       listen 514 tcp;
11
       proxy_pass wzmsyslog;
12
   }
13
}

1
sudo nginx -t
2
sudo systemctl reload nginx
3
sudo netstat -tlnp | grep :514

1
<ossec_config>
2
  <remote>
3
    <connection>syslog</connection>
4
    <port>514</port>
5
    <protocol>tcp</protocol>
6
    <allowed-ips>10.x.x.x/16</allowed-ips>
7
    <local_ip>0.0.0.0</local_ip>
8
  </remote>
9
</ossec_config>

1
# On the syslog-ng VM, monitor incoming connections
2
sudo tail -f /var/log/messages | grep syslog-ng
3

4
# Or check for active TLS connections on port 6514
5
sudo netstat -tnlp | grep 6514
6

7
# Check actual packets are coming if you don't see connections from previous commands
8
sudo tcpdump -i eth0 src port 6514
9

10
# on another machine use netcat to connect to the port
11
nc 10x.x.x.x 6514

1
# Check syslog-ng statistics
2
sudo syslog-ng-ctl stats
3
# Look for destination "d_wazuh" statistics

Creating decoders and rulesSection titled Creating%20decoders%20and%20rules

Now that we are receiving the syslog messages we can see that Keeper uses the JSON format for the message payload. This makes it very easy to create a single decoder with a variable number of fields.

Open the Wazuh dashboard and go to Server Management > Decoders and click on Add new decoders file. In the file name add your desired name, in my case I use this format XXXX-keeper.xml, and add the following content:

1
<!--Parent decoder-->
2
<decoder name="keeper_audit">
3
  <prematch>keeper - - -</prematch>
4
</decoder>
5

6
<!--JSON Fields decoder-->
7
<decoder name="keeper_audit_fields">
8
  <parent>keeper_audit</parent>
9
  <prematch>keeper - - -</prematch>
10
  <plugin_decoder offset="after_parent">JSON_Decoder</plugin_decoder>
11
</decoder>
12

13
<!--Event timestamp decoder-->
14
<decoder name="keeper_audit_fields">
15
  <parent>keeper_audit</parent>
16
  <regex type="pcre2">.*(\d{4}\-\d{2}\-\d{2}T\d{2}\:\d{2}\:\d{2}\.\d{3}Z)</regex>
17
  <order>event_timestamp</order>
18
</decoder>

This will decode the JSON payload of the syslog message and additionally will extract the event timestamp as that is not part of the JSON payload that Keeper sends us.

The two decoders sharing the same name are intentionally designed this way. This naming convention allows Wazuh to merge the outputs of both decoders into a single, unified result.

With the decoders in place let’s add a few rules, by going to Server management > Rules. Click the Add new rules file and give it a name, I used keeper_logs.xml, and add the following content:

1
<group name="keeper">
2
    <!--Alert when a failed login is seen-->
3
    <rule id="119011" level="10">
4
        <decoded_as>keeper_audit</decoded_as>
5
        <field name="audit_event">login_failure</field>
6
        <field name="category">login</field>
7
        <description>Keeper user [$(username)] has failed to login via [$(channel)] using [$(client_version)] with [$(result_code)] from [$(remote_address)]</description>
8
    </rule>
9

10
    <!--Alert when multiple failed logins are seen-->
11
    <rule id="119012" level="14" frequency="3" timeframe="300">
12
        <if_matched_sid>119011</if_matched_sid>
13
        <description>Keeper user [$(username)] has failed multiple times to login via [$(channel)] using [$(client_version)] with [$(result_code)] from [$(remote_address)]</description>
14
    </rule>
15
</group>

This creates two alerts, one for a single failed login and one triggered when multiple failed logins are seen which might indicate that a credential attack is underway.

Now you can monitor and create alerts for more than 100 events grouped by event type. This gives us a lot of flexibility in monitoring and alerting the security team based on the organization’s interests.

1
<!-- Alert on administrative actions -->
2
<rule id="119020" level="8">
3
    <decoded_as>keeper_audit</decoded_as>
4
    <field name="category">account|security|policy|managed_company|msp</field>
5
    <description>Keeper administrative action: [$(audit_event)] by [$(username)]</description>
6
    <group>keeper,administrative,</group>
7
</rule>
8

9
<!-- Alert on external sharing -->
10
<rule id="119030" level="9">
11
    <decoded_as>keeper_audit</decoded_as>
12
    <field name="audit_event">ext_share_added|ext_share_removed</field>
13
    <description>User [$(username)] performed [$(audit_event)] on a One-Time Share link to 'Record UID:$(app_uid)'</description>
14
    <group>keeper,sharing,external,</group>
15
</rule>
16

17
<!-- Alert on vault record deletion -->
18
<rule id="119040" level="12">
19
    <decoded_as>keeper_audit</decoded_as>
20
    <field name="audit_event">record_delete|deleted_folder</field>
21
    <description>Keeper CRITICAL: [$(username)] deleted [$(audit_event)]</description>
22
    <group>keeper,deletion,critical,</group>
23
</rule>

Next stepsSection titled Next%20steps

With the integration in place and operational, here are some ideas for your security team:

Expand the detection rules: Beyond failed logins, consider creating rules for:

• Vault record sharing events (both internal and external)
• Administrative changes (user additions, role modifications, policy changes)
• Privileged session activities from KeeperPAM
• Credential rotation events from Secrets Manager
• After-hours access to critical vaults

Create Custom Dashboards: Build Wazuh dashboards that give you at-a-glance visibility into:

• Failed authentication attempts by user and source IP
• After-hours access attempts
• Administrative actions timeline
• Geographic distribution of access (if using GeoIP enrichment)

Implement Automated Responses: Configure Wazuh active response to take action on critical events:

• Email notifications for high-severity alerts
• Perform administrative actions using Keeper Commander
• Automated ticket creation in your ITSM platform

Correlate with Other Security Data:

• Cross-reference Keeper credential access with authentication logs from target systems
• Correlate PAM session starts with EDR process execution data
• Link administrative changes to change management tickets

Some of these I’ve implemented myself, and they helped a lot to improve my understanding of Keeper usage in the organization.

ConclusionSection titled Conclusion

Integrating Keeper’s audit logs with Wazuh has transformed how I monitor privileged access. What was once scattered across Keeper’s Admin Console and periodic export files is now a real-time security monitoring system that alerts me to potential threats before they escalate.

The architecture I’ve shared, using syslog-ng as an internet-facing intermediary with TLS encryption, load-balanced Wazuh managers, and custom detection rules, provides both security and reliability. Yes, it’s an extra VM to manage, but the security isolation it provides is worth the operational overhead.

The two rules I’ve included are just a starting point. Keeper logs over 100 event types, and you should build rules that align with your organization’s risk profile. Monitor failed logins for credential attacks, track external sharing for data exfiltration, and alert on administrative changes for audit trails are just a few examples that you try.

If you’ve been following my Keeper PAM PoC, this monitoring layer completes the privileged access security stack: secure storage, managed access, and comprehensive visibility. Together, I believe these form the foundation of a mature PAM program.

I’d love to hear about your experiences integrating Keeper with Wazuh. What challenges did you face? What additional rules have you found valuable?

Drop your thoughts in the comments or reach out directly.