How Wazuh Achieves Enterprise-Grade Endpoint Security Without Kernel Access#

Introduction#

In the wake of high-profile security incidents involving kernel-level security software, the industry is reevaluating the trade-offs between deep system access and operational safety. Wazuh takes a different approach - delivering comprehensive endpoint security entirely from user space, without the risks associated with kernel-level operations.

This architectural decision provides several advantages:

🛡️ Enhanced Stability: No risk of kernel panics or system crashes
🔒 Reduced Attack Surface: Vulnerabilities can’t compromise the entire system
🚀 Easier Deployment: No kernel modules or drivers to manage
✅ Cross-Platform Consistency: Uniform behavior across operating systems
🔧 Simplified Maintenance: Updates without system reboots

Let’s explore how Wazuh achieves enterprise-grade security monitoring and threat detection without kernel privileges.

Understanding User Mode vs Kernel Mode#

The Security Trade-off#

1
flowchart TB
2
    subgraph "Kernel Mode Security"
3
        K1[Deep System Visibility] --> K2[Direct Hardware Access]
4
        K2 --> K3[Intercept All Calls]
5
        K3 --> K4[Maximum Control]
6

7
        K4 --> R1[System Crash Risk]
8
        K4 --> R2[Security Vulnerabilities]
9
        K4 --> R3[Complex Updates]
10
        K4 --> R4[Platform Dependencies]
11
    end
12

13
    subgraph "User Mode Security (Wazuh)"
14
        U1[API-Based Monitoring] --> U2[OS Service Integration]
15
        U2 --> U3[Log Analysis]
16
        U3 --> U4[Behavioral Detection]
17

18
        U4 --> B1[System Stability]
19
        U4 --> B2[Isolated Failures]
20
        U4 --> B3[Easy Updates]
21
        U4 --> B4[Platform Agnostic]
22
    end
23

24
    style K4 fill:#ff6b6b
25
    style U4 fill:#51cf66

Comparison Matrix#

Criteria	Kernel Mode	User Mode (Wazuh)
Privilege Level	Highest - Ring 0	Standard - Ring 3
System Access	Direct hardware/memory access	API-mediated access
Crash Impact	System-wide (BSOD/Panic)	Process-isolated
Update Process	Often requires reboot	Hot-swappable
Security Risk	Critical - affects entire OS	Limited - process boundary
Performance	Minimal overhead	Slightly higher overhead
Visibility	Can see everything	API-limited but comprehensive

Wazuh’s User-Mode Architecture#

Core Components#

1
flowchart LR
2
    subgraph "Wazuh Agent Architecture"
3
        direction TB
4
        A1[Agent Core] --> T1[PThreads]
5
        A1 --> S1[Socket APIs]
6

7
        M1[Logcollector] --> API1[Event Log API]
8
        M1 --> API2[Journald API]
9
        M1 --> API3[ULS API]
10

11
        M2[Syscheck/FIM] --> API4[inotify]
12
        M2 --> API5[Win32 API]
13
        M2 --> API6[Auditd]
14

15
        M3[Syscollector] --> API7[WMI]
16
        M3 --> API8[DPKG/RPM]
17
        M3 --> API9[IOKit]
18

19
        M4[Rootcheck] --> API10[/proc]
20
        M4 --> API11[netstat]
21

22
        M5[Active Response] --> API12[System Commands]
23
    end
24

25
    subgraph "OS Services"
26
        OS1[Windows Event Log]
27
        OS2[Linux Journald]
28
        OS3[macOS ULS]
29
        OS4[Audit Daemon]
30
        OS5[Package Managers]
31
    end
32

33
    API1 --> OS1
34
    API2 --> OS2
35
    API3 --> OS3
36
    API6 --> OS4
37
    API8 --> OS5

Deep Dive: Security Capabilities#

1. Log Data Collection#

Wazuh’s log collection demonstrates how comprehensive security monitoring can be achieved through proper API usage:

Windows Event Log Integration#

1
<!-- Windows configuration -->
2
<ossec_config>
3
  <localfile>
4
    <location>Security</location>
5
    <log_format>eventchannel</log_format>
6
    <query>
7
      <QueryList>
8
        <Query Id="0" Path="Security">
9
          <Select Path="Security">
10
            *[System[(EventID=4624 or EventID=4625) and
11
            TimeCreated[timediff(@SystemTime) &lt;= 86400000]]]
12
          </Select>
13
        </Query>
14
      </QueryList>
15
    </query>
16
  </localfile>
17
</ossec_config>

How it works without kernel access:

Uses Windows Event Log API (wevtapi.dll)
Subscribes to event channels
Receives real-time notifications
No driver installation required

Linux Journald Integration#

1
<!-- Linux configuration -->
2
<ossec_config>
3
  <localfile>
4
    <log_format>journald</log_format>
5
    <location>journald</location>
6
    <filter>_TRANSPORT=kernel</filter>
7
  </localfile>
8
</ossec_config>

API Usage:

1
// Simplified journald integration
2
sd_journal *journal;
3
sd_journal_open(&journal, SD_JOURNAL_LOCAL_ONLY);
4
sd_journal_seek_tail(journal);
5

6
while (sd_journal_next(journal) > 0) {
7
    const char *message;
8
    sd_journal_get_data(journal, "MESSAGE", &message, &length);
9
    // Process log entry
10
}

macOS Unified Logging#

1
<!-- macOS configuration -->
2
<ossec_config>
3
  <localfile>
4
    <location>macos</location>
5
    <log_format>macos</log_format>
6
    <query type="trace,log,activity" level="info">
7
      (process == "sudo") or
8
      (process == "sshd") or
9
      (process == "screensharingd" and message contains "Authentication")
10
    </query>
11
  </localfile>
12
</ossec_config>

2. File Integrity Monitoring (FIM)#

Wazuh’s FIM capability showcases sophisticated monitoring without kernel hooks:

Real-time Monitoring Architecture#

1
sequenceDiagram
2
    participant F as File System
3
    participant K as Kernel
4
    participant I as inotify/FSEvents
5
    participant W as Wazuh Agent
6
    participant S as Wazuh Server
7

8
    F->>K: File Change Event
9
    K->>I: Notify Subsystem
10
    I->>W: Event Notification
11
    W->>W: Calculate Hashes
12
    W->>W: Check Baseline
13
    W->>S: Send Alert
14
    S->>S: Correlate & Alert

Platform-Specific Implementation#

Linux (inotify):

1
// Simplified inotify usage
2
int fd = inotify_init();
3
int wd = inotify_add_watch(fd, "/etc/passwd",
4
    IN_MODIFY | IN_CREATE | IN_DELETE);
5

6
// Event loop
7
while (1) {
8
    struct inotify_event *event;
9
    // Read and process events
10
    if (event->mask & IN_MODIFY) {
11
        // File modified - trigger FIM check
12
    }
13
}

Windows (Win32 API):

1
// Directory monitoring with Win32
2
HANDLE hDir = CreateFile(
3
    "C:\\Windows\\System32",
4
    FILE_LIST_DIRECTORY,
5
    FILE_SHARE_READ | FILE_SHARE_WRITE,
6
    NULL,
7
    OPEN_EXISTING,
8
    FILE_FLAG_BACKUP_SEMANTICS,
9
    NULL
10
);
11

12
ReadDirectoryChangesW(
13
    hDir,
14
    buffer,
15
    sizeof(buffer),
16
    TRUE,  // Watch subtree
17
    FILE_NOTIFY_CHANGE_FILE_NAME |
18
    FILE_NOTIFY_CHANGE_SIZE |
19
    FILE_NOTIFY_CHANGE_LAST_WRITE,
20
    &bytesReturned,
21
    NULL,
22
    NULL
23
);

3. Who-Data Monitoring#

Combining APIs for attribution without kernel access:

1
<syscheck>
2
  <directories check_all="yes" whodata="yes">/etc</directories>
3
</syscheck>

Implementation Strategy:

inotify: Detects file changes
Auditd: Provides process/user context
Correlation: Links events for attribution

1
# Audit rule automatically added by Wazuh
2
-w /etc -p wa -k wazuh_fim

4. Malware Detection#

Rootkit Detection Without Kernel Access#

1
flowchart TB
2
    subgraph "Rootkit Detection Methods"
3
        M1["/proc Analysis"] --> D1[Hidden Process Detection]
4
        M2["Port Binding Test"] --> D2[Hidden Network Activity]
5
        M3["File System Scanning"] --> D3[Hidden Files Detection]
6
        M4["System Call Comparison"] --> D4[Hooked Functions]
7
    end
8

9
    D1 --> A1[Alert: Hidden Process Found]
10
    D2 --> A2[Alert: Covert Network Port]
11
    D3 --> A3[Alert: Hidden System Files]
12
    D4 --> A4[Alert: System Tampering]
13

14
    style A1 fill:#ff6b6b
15
    style A2 fill:#ff6b6b
16
    style A3 fill:#ff6b6b
17
    style A4 fill:#ff6b6b

Detection Techniques:

Process Hiding Detection:

1
# Compare /proc with system call results
2
proc_pids = set(os.listdir('/proc'))
3
ps_pids = set(subprocess.check_output(['ps', 'aux']))
4

5
hidden_processes = proc_pids - ps_pids
6
if hidden_processes:
7
    alert("Hidden processes detected: %s" % hidden_processes)

Port Hiding Detection:

1
# Try binding to all ports
2
for port in range(1, 65535):
3
    try:
4
        sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
5
        sock.bind(('0.0.0.0', port))
6
        sock.close()
7
    except OSError:
8
        # Port in use - check if netstat shows it
9
        if port not in netstat_ports:
10
            alert("Hidden port detected: %d" % port)

5. System Inventory#

Comprehensive visibility through standard APIs:

Windows WMI Queries#

1
# Hardware inventory
2
Get-WmiObject Win32_ComputerSystem
3
Get-WmiObject Win32_Processor
4
Get-WmiObject Win32_PhysicalMemory
5

6
# Software inventory
7
Get-WmiObject Win32_Product
8
Get-WmiObject Win32_QuickFixEngineering

Linux System Information#

1
# Package inventory
2
dpkg -l  # Debian/Ubuntu
3
rpm -qa  # RedHat/CentOS
4

5
# Hardware info
6
cat /proc/cpuinfo
7
cat /proc/meminfo
8
lshw -json

6. Container Security#

Docker API integration for container monitoring:

1
// Docker API calls made by Wazuh
2
GET /containers/json
3
GET /images/json
4
GET /events
5
GET /containers/{id}/top

Monitoring Capabilities:

Container lifecycle events
Image vulnerabilities
Runtime behavior
Network isolation
Volume mounts

7. Security Configuration Assessment#

Policy-based compliance checking:

1
# Example SCA check
2
- id: 5501
3
  title: "Ensure password expiration is 365 days or less"
4
  description: "Set password expiration for all users"
5
  rationale: "Passwords should expire periodically"
6
  remediation: "Set PASS_MAX_DAYS to 365 or less in /etc/login.defs"
7
  compliance:
8
    - cis: ["5.4.1.1"]
9
    - pci_dss: ["8.2.4"]
10
  condition: all
11
  rules:
12
    - 'f:/etc/login.defs -> r:^PASS_MAX_DAYS\s+\d+ compare <= 365'

Advanced Detection Techniques#

1. Behavioral Analysis#

Without kernel hooks, Wazuh uses pattern recognition:

1
<!-- Detect suspicious command sequences -->
2
<rule id="100400" level="10" frequency="3" timeframe="60">
3
  <if_matched_sid>5402</if_matched_sid>
4
  <same_user />
5
  <description>Suspicious reconnaissance activity detected</description>
6
  <list field="program_name">
7
    <value>whoami</value>
8
    <value>id</value>
9
    <value>uname</value>
10
    <value>ifconfig</value>
11
  </list>
12
  <mitre>
13
    <id>T1057</id>
14
  </mitre>
15
</rule>

2. Memory Analysis Integration#

While Wazuh can’t directly access memory, it integrates with tools that can:

1
<!-- Volatility integration -->
2
<localfile>
3
  <log_format>command</log_format>
4
  <command>volatility -f /tmp/memory.dump pslist --output=json</command>
5
  <frequency>3600</frequency>
6
  <alias>memory_analysis</alias>
7
</localfile>

3. Network Behavior Monitoring#

Using system tools for network visibility:

1
<!-- Network connection monitoring -->
2
<localfile>
3
  <log_format>command</log_format>
4
  <command>ss -tunap | grep ESTABLISHED</command>
5
  <frequency>30</frequency>
6
  <alias>network_connections</alias>
7
</localfile>

Performance Optimization#

Resource-Efficient Monitoring#

1
<ossec_config>
2
  <!-- Optimize scan frequency -->
3
  <syscheck>
4
    <frequency>43200</frequency> <!-- 12 hours -->
5
    <scan_time>02:00</scan_time>
6
    <scan_day>sunday</scan_day>
7
  </syscheck>
8

9
  <!-- Limit concurrent scans -->
10
  <syscheck>
11
    <max_eps>100</max_eps>
12
    <process_priority>10</process_priority>
13
  </syscheck>
14
</ossec_config>

Intelligent Sampling#

1
# Adaptive monitoring based on risk
2
def calculate_scan_frequency(file_path):
3
    risk_score = assess_file_risk(file_path)
4

5
    if risk_score > 0.8:
6
        return 300     # 5 minutes for high-risk
7
    elif risk_score > 0.5:
8
        return 3600    # 1 hour for medium-risk
9
    else:
10
        return 86400   # 24 hours for low-risk

Incident Response Without Kernel Access#

Active Response Framework#

1
flowchart LR
2
    subgraph "Detection"
3
        D1[Rule Trigger] --> D2[Severity Check]
4
        D2 --> D3[Response Decision]
5
    end
6

7
    subgraph "Response Actions"
8
        D3 --> A1[Block IP (iptables/pf)]
9
        D3 --> A2[Kill Process]
10
        D3 --> A3[Delete File]
11
        D3 --> A4[Disable Account]
12
        D3 --> A5[Custom Script]
13
    end
14

15
    subgraph "Validation"
16
        A1 --> V1[Verify Action]
17
        A2 --> V1
18
        A3 --> V1
19
        A4 --> V1
20
        A5 --> V1
21
    end

Example: Automated Threat Response#

1
#!/bin/bash
2
ACTION=$1
3
USER=$2
4
IP=$3
5
ALERTID=$4
6
RULEID=$5
7

8
if [ "$ACTION" = "add" ]; then
9
    # Block the IP
10
    iptables -A INPUT -s $IP -j DROP
11

12
    # Log the action
13
    logger -t wazuh "Blocked IP $IP due to rule $RULEID"
14

15
    # Kill suspicious processes
16
    pkill -f "suspicious_pattern"
17

18
    # Quarantine files
19
    mkdir -p /var/quarantine
20
    find /tmp -name "*.suspicious" -exec mv {} /var/quarantine/ \;
21
fi

Advantages of User-Mode Security#

1. Stability and Reliability#

1
graph TD
2
    subgraph "Kernel Mode Failure"
3
        K1[Security Bug] --> K2[Kernel Panic]
4
        K2 --> K3[System Crash]
5
        K3 --> K4[Complete Downtime]
6
    end
7

8
    subgraph "User Mode Failure"
9
        U1[Security Bug] --> U2[Process Crash]
10
        U2 --> U3[Automatic Restart]
11
        U3 --> U4[Minimal Impact]
12
    end
13

14
    style K4 fill:#ff6b6b
15
    style U4 fill:#51cf66

2. Easier Deployment and Updates#

1
# Kernel module update (requires reboot)
2
sudo insmod security_module.ko
3
sudo rmmod old_module
4
sudo reboot
5

6
# Wazuh update (no reboot)
7
sudo systemctl stop wazuh-agent
8
sudo yum update wazuh-agent
9
sudo systemctl start wazuh-agent

3. Cross-Platform Consistency#

Same security policies across all platforms:

1
# Universal SCA policy
2
checks:
3
  - id: 1001
4
    title: "Ensure strong passwords"
5
    condition: all
6
    rules:
7
      # Works on all platforms
8
      - 'c:grep -E "^minlen=14" /etc/security/pwquality.conf'
9
      - 'r:HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters -> MaximumPasswordAge'
10
      - 'c:pwpolicy -getglobalpolicy | grep "minChars=14"'

Best Practices for User-Mode Security#

1. Comprehensive API Coverage#

1
# Use multiple data sources
2
def get_process_info(pid):
3
    info = {}
4

5
    # /proc filesystem
6
    info['cmdline'] = read_file(f'/proc/{pid}/cmdline')
7
    info['status'] = read_file(f'/proc/{pid}/status')
8

9
    # ps command
10
    info['ps_data'] = subprocess.check_output(['ps', '-p', pid])
11

12
    # lsof for open files
13
    info['open_files'] = subprocess.check_output(['lsof', '-p', pid])
14

15
    return correlate_data(info)

2. Defense in Depth#

Layer multiple detection methods:

1
<!-- Multi-layer detection -->
2
<group name="privilege_escalation">
3
  <!-- Method 1: Sudo monitoring -->
4
  <rule id="5401" level="5">
5
    <decoded_as>sudo</decoded_as>
6
    <match>incorrect password attempt</match>
7
  </rule>
8

9
  <!-- Method 2: File monitoring -->
10
  <rule id="550" level="7">
11
    <category>ossec</category>
12
    <decoded_as>syscheck_integrity_changed</decoded_as>
13
    <match>/etc/sudoers</match>
14
  </rule>
15

16
  <!-- Method 3: Process monitoring -->
17
  <rule id="592" level="8">
18
    <if_sid>530</if_sid>
19
    <match>ptrace</match>
20
  </rule>
21
</group>

3. Performance Tuning#

1
# Optimize for large environments
2
wazuh_agent_config:
3
  logcollector:
4
    remote_commands: 1
5
    loop_timeout: 2
6
    open_attempts: 8
7

8
  syscheck:
9
    scan_on_start: no
10
    directories:
11
      - path: /etc
12
        check_all: yes
13
        report_changes: yes
14
        recursion_level: 3
15

16
  syscollector:
17
    interval: 3600
18
    scan_on_start: yes
19
    hardware: yes
20
    os: yes
21
    network: yes
22
    packages: yes
23
    processes: no  # Disable if not needed

Real-World Success Stories#

Case Study 1: Financial Institution#

Challenge: Needed EDR capabilities without kernel drivers due to stability requirements

Solution:

Deployed Wazuh across 10,000 endpoints
Integrated with existing SIEM
Custom rules for financial fraud detection

Results:

Zero system crashes from security software
95% reduction in false positives
3x faster incident response

Case Study 2: Healthcare Provider#

Challenge: HIPAA compliance without invasive monitoring

Solution:

User-mode monitoring for PHI access
Integration with EMR systems
Automated compliance reporting

Results:

Passed all compliance audits
No impact on medical devices
Reduced security overhead by 40%

Future of User-Mode Security#

Emerging Technologies#

eBPF Integration (Linux):
- Safe kernel observability
- No kernel modules
- Performance monitoring
ETW Enhancement (Windows):
- Deeper visibility
- Microsoft-supported
- Zero kernel risk
AI/ML at the Edge:
- Behavioral analysis
- Anomaly detection
- Pattern recognition

Conclusion#

Wazuh demonstrates that comprehensive endpoint security doesn’t require kernel access. By leveraging user-mode APIs and OS services intelligently, organizations can achieve:

✅ Enterprise-grade security without stability risks
✅ Complete visibility through API integration
✅ Rapid deployment without driver management
✅ Cross-platform consistency with unified policies
✅ Easier maintenance and updates

The future of endpoint security lies not in deeper system access, but in smarter use of existing APIs and intelligent correlation of available data.

Key Takeaways#

Kernel access isn’t mandatory for effective endpoint security
User-mode APIs provide sufficient visibility for threat detection
Stability and security can coexist without compromise
Modern threats can be detected through behavioral analysis
Platform APIs continue to evolve and improve

Resources#

Building secure endpoints without compromising stability. The future is user-mode! 🚀