Post cover image

September 24, 2026

Building Wazuh Mobile Sentinel: Bringing Mobile Visibility to a SIEM That Doesn’t Have It (Yet)

The gap

By Muhammad Ahmad Abid

6 min read

The gap

Wazuh covers Linux, Windows, macOS, cloud workloads, even containers but there's no official mobile agent. It's not an oversight nobody's noticed either: there's an open feature request on Wazuh's own GitHub repo (#32881) asking for exactly this, and a Wazuh blog post on forwarding Android syslog that closes with an open invitation for the community to build in this space.

Mobile devices carry as much (arguably more) sensitive exposure as a laptop on the network email, banking apps, corporate messaging, VPN clients and they're often completely outside a SOC's visibility. I wanted to fix a sliver of that, as a real open-source contribution rather than a class project.

What I built

Wazuh Mobile Sentinel, a small Android app (Kotlin, no root required) that reports device security posture to a Wazuh manager. It collects:

  • OS version, security patch level, manufacturer/model
  • Installed app count (total + user-installed)
  • Storage encryption status
  • Screen lock configuration
  • Developer options / USB debugging state
  • VPN and network connection type
  • A Play Integrity API signal (root/tamper indicator)
  • Real-time new-app-install detection, including whether an app was sideloaded and whether it requests sensitive permissions (SMS, contacts, camera, mic, location, install-packages)

The pipeline: the Android app POSTs JSON to a lightweight Flask receiver, which appends structured log lines that a Wazuh manager picks up through standard log monitoring. Custom Wazuh rules turn that into alerts — including a correlation rule that escalates severity when multiple weak signals (e.g. USB debugging and no screen lock) appear on the same device within a two-minute window.

None

Running on real hardware, a Redmi Note 13.

Same app, same result, on a stock Android emulator, confirms it's not device-specific.

None None 
Android App (Kotlin)
   |  JSON payload
   v
Flask receiver (EC2)
   v
Wazuh manager (log monitoring)
   |  built-in JSON decoding + custom rules
   v
Wazuh Dashboard — alerts, Threat Hunting

Deliberately not an MDM. Consumer security apps (Zimperium, Lookout, etc.) don't expose their data through an open API — it stays in their own cloud. Enterprise MDM does, but needs enterprise enrollment and is far heavier than most Wazuh setups need. This sits in between: no MDM infrastructure, no vendor lock-in, built entirely on public Android APIs and Wazuh's existing log-ingestion model.

Two problems that weren't obvious at all

1. Wazuh's own JSON decoder was fighting my custom one

Every custom decoder I wrote, even a near-empty one with just <parent>json</parent> and a <prematch> silently broke Wazuh's automatic JSON field extraction. Rule descriptions referencing $(device_id) came back empty, even though wazuh-logtest showed the rule technically firing.

I tried chaining parent/child decoders, use_own_name, different combinations of prematch and regex/order — each fixed one symptom and broke another (sometimes crashing wazuh-manager outright with "Parent decoder name invalid").

The fix was to stop fighting it: delete the custom decoder entirely, let Wazuh's built-in json decoder auto-extract every field (it does this natively for valid single-object JSON logs), and write rules that match on <decoded_as>json</decoded_as> plus a <regex> against the raw text rather than relying on <field> conditions. That combination gave both correct field substitution and reliable rule firing.

None

Sometimes the fix is to delete code, not write more of it.

2. App-install detection silently didn't work on any device

This was the harder one. AppInstallReceiver, listening for PACKAGE_ADDED/PACKAGE_REPLACED, simply never fired. Not on the emulator, not on a real Redmi Note 13, regardless of permissions.

I chased a few plausible leads first:

  • Suspected the app needed a first manual open before receiving broadcasts (partially true, but not the full story)
  • Suspected MIUI/HyperOS-specific battery or autostart restrictions — added QUERY_ALL_PACKAGES to fix a real (but separate) Android 11+ package-visibility issue, and tried whitelisting the app via dumpsys deviceidle and am set-standby-bucket. No change.
  • Built an isolated dummy test app to eliminate any self-install confound, and reproduced the exact same failure on both a stock emulator and real MIUI hardware — ruling out an OEM-specific cause.

The actual root cause showed up in adb shell dumpsys activity broadcasts history-forced:

reason: skipped by policy at enqueue: Background execution not allowed:
receiving Intent { ... PACKAGE_ADDED ... } to
com.wazuh.mobilesentinel/.receivers.AppInstallReceiver

And the same exact skip reason was applied, in the same broadcast history dump, to Google's own Play Store, Play Services, and Google Search receivers. This isn't an app bug or an OEM quirk — it's Android's platform-level Background Execution Limits (introduced in Android 8) silently dropping manifest-declared broadcast receivers for any app that isn't in the foreground.

None

Tracing broadcast delivery through dumpsys — this is what finally pointed at the platform-level restriction instead of an app bug.

The fix: register the receiver dynamically, from inside an active foreground service (MonitoringService, started via startForeground()), instead of declaring it as a static <receiver> in the manifest. A receiver registered on a live process isn't subject to that same restriction. After this change, install events fired reliably and reached the Wazuh dashboard in real time — verified on both the emulator and a real device, installing real Play Store apps.

The rules, and proof they work

The full rule set, 8 posture rules, 3 app-install rules, and the correlation rule:

None None

Each rule was individually verified with wazuh-logtest before trusting it in production. Here's the Play Integrity failure rule firing correctly:

None

And here's a simulated sideloaded, sensitive-permission app correctly escalating to the highest-severity install rule:

None

The real proof, though, is real Play Store apps triggering real-time detection on actual hardware not a simulated payload:

None None

These are real installs from the Play Store on my own phone, captured the moment they happened.

What it looks like in the Dashboard

This is the point of the whole pipeline — alerts showing up where a SOC analyst actually works:

None

USB debugging, Play Integrity failures, sideloaded installs, and the correlation rule — all visible side by side.

None

Field substitution working end to end: device_id and package_name both populated correctly in the alert detail.

Where it stands

Verified end-to-end: all 11 individual rules plus the correlation rule tested via wazuh-logtest, confirmed live in the Wazuh Dashboard's Threat Hunting view, on both a Pixel 7 emulator (Android 14) and a real Redmi Note 13 (Android 15, HyperOS).

Not yet done, and documented as such:

  • Full Play Integrity server-side verification (needs a registered Google Cloud project + Play Console linkage)
  • Scheduled/background posture collection beyond the manual trigger (install detection is already real-time)
  • iOS — intentionally out of scope

Why write this up

This started as a "can Wazuh even do mobile" question and turned into two genuinely non-obvious platform-level debugging problems that I couldn't find documented together anywhere. If you're building anything similar — a Wazuh integration, or any Android app relying on install broadcasts — I hope the dumpsys activity broadcasts history-forced trick in particular saves someone else the same few hours I spent on it.

Code, README and setup instructions: https://github.com/cyberxperts29-sudo/wazuh-mobile-sentinel

Feedback, issues and PRs welcome — this is meant to grow as a real community contribution, in the spirit of the original Wazuh issue that inspired it.