Anomaly Detection (Premium)

Chada Activity Monitor’s anomaly detection engine watches the event stream for patterns that suggest a security incident or unusual behaviour. When a rule fires, an anomaly record is created and a badge appears on the Anomalies menu item showing the count of unacknowledged anomalies. This feature requires an active premium license.

The five anomaly rules

1. Failed login burst

Fires when the number of failed login events from the same IP address or for the same username exceeds the configured threshold within a rolling time window. Used to detect brute-force and credential-stuffing attacks.

• Setting: anomaly_failed_login_threshold (default 10 failures) and anomaly_failed_login_window (default 15 minutes).

2. Privilege escalation

Fires whenever any user’s role is changed to a role with more capabilities — for example, changing a Subscriber to an Editor, or an Editor to an Administrator. Auto-detected from the core.user_updated event; no threshold to configure.

3. New administrator

Fires whenever a new user is registered or an existing user’s role is set to administrator. Auto-detected. Deduplication prevents a second anomaly if the same user account triggers both a role change and a profile update in the same session.

4. Mass deletion

Fires when the number of delete events (posts permanently deleted, users deleted, or terms deleted) from the same actor exceeds the configured threshold within a rolling time window. Detects accidental or malicious bulk deletions.

• Setting: anomaly_mass_deletion_threshold (default 20 items) and anomaly_mass_deletion_window (default 5 minutes).

5. Off-hours activity

Fires when any Critical-severity event occurs outside the configured quiet hours. Useful for detecting after-hours admin access on sites that should only be administered during business hours.

• Setting: anomaly_quiet_start and anomaly_quiet_end in 24-hour format (e.g., 22 for 10 PM and 06 for 6 AM). Events between these hours trigger the rule.

Deduplication

The engine prevents duplicate anomaly rows for the same ongoing event. If a brute-force attack is still producing failed logins after an anomaly has already been raised, no additional anomaly record is created until the existing one is acknowledged and a new burst begins.

Acknowledging anomalies

Each anomaly on the Activity Log → Anomalies screen has an Acknowledge button. Clicking it marks the anomaly as reviewed, removes it from the unacknowledged count, and collapses it in the list. Acknowledged anomalies remain in the database for your records but no longer appear in the badge count.

Email notification for anomalies

Enable the Email on anomaly setting (email_anomaly) to receive an immediate email to the WordPress admin_email address whenever an anomaly is raised. The email includes the rule name, a description of what triggered it, and a link to the Anomalies screen.

Enabling anomaly detection

Anomaly detection is controlled by the anomaly_enabled setting under Settings → Anomaly Detection. Toggle it on to activate all five rules. Individual rules cannot currently be disabled separately — if a specific rule produces too many false positives, adjust its threshold rather than disabling detection entirely.