How events are classified: normal, strange, dangerous

Why classify at all

A plain activity log has a discovery problem: on a real site it produces hundreds of rows a week, almost all of them boring, and the two that matter are indistinguishable from the rest until you already know what you are looking for. Classification is the plugin's answer. Every event is scored as it is recorded, and the reason for anything above normal is stored alongside the row in plain words.

There are three levels:

• Normal — routine operation. Someone published a post, someone logged in at lunchtime.
• Strange — unusual but not necessarily harmful. A failed login, a settings change, a new user account.
• Dangerous — look at this now. A new administrator, the file editor being used, payment settings changing. Dangerous events also email you.

Stage one: base severity

Every event type has a starting severity. Most are normal; a few are dangerous the moment they happen regardless of who did it. Two examples of the latter are worth calling out because they explain the philosophy:

• file_edited is always dangerous. Editing theme or plugin code from wp-admin means arbitrary PHP now runs on your site. Even when it is you doing it deliberately, it is the single highest-consequence action available in the dashboard.
• log_purged is always dangerous. Wiping the audit trail is a legitimate button the plugin itself provides, and it is also the classic cover-your-tracks move — so it alerts either way, and it is recorded as the first event of the fresh log.

The full table of starting severities is in the event reference.

Stage two: rule overrides

Some events are only dangerous depending on what exactly changed. These rules replace the base severity outright:

• A new administrator account was created — user_created with the administrator role becomes dangerous.
• A user was promoted to administrator — user_role_changed with a new role of administrator becomes dangerous.
• A sensitive option changed — changes to siteurl, home, admin_email or default_role become dangerous. These four are site-takeover vectors: redirect the site, hijack password resets, or make every new signup an editor.
• Open registration was enabled — switching on users_can_register becomes dangerous.
• A price dropped by more than half — a WooCommerce product_price_changed where the new price is under half the old one is escalated one level, on the reasoning that steep unexplained discounts are a signature of a compromised account.

Stage three: contextual heuristics

The remaining rules compare the event to recent history rather than to a fixed list. Each one that fires bumps the severity up a level and appends its reason:

• Login at an unusual hour. A user_login between midnight and 05:00 site time is escalated.
• Login from a new IP. A user_login from an address never previously seen for that specific user is escalated. This is per-user, not per-site, so a new team member logging in for the first time reads differently from a long-standing admin appearing from a new country.
• Brute force. Five or more login_failed events from the same IP within 15 minutes makes the event dangerous outright, with the attempt count in the reason.
• Deletion bursts. Five or more deletions by the same user within 10 minutes — across posts, attachments, users, plugins and themes — makes the event dangerous. A single deletion is routine; twenty in a row is either a mistake or an attack, and both are worth an email.

Note that escalations stack: a login at 03:00 from an unseen IP fires two rules, so a normally-normal login lands on dangerous and emails you, with both reasons listed.

Events that can never be muted

You can mute any event type you find noisy (see the settings reference), with three exceptions that audit the auditor itself: settings_changed, settings_reset and log_purged. If muting were allowed there, an attacker with admin access could silence the plugin and then wipe the log without leaving a trace of either action.

Families

Independently of severity, every event belongs to one of nine families — authentication, users, content, plugins, themes, core, settings, commerce, and a catch-all for events registered by other code. Families are what the log filter and the per-family retention windows operate on. Severity answers "how alarming is this?"; family answers "what part of the site is this about?".

Changing the classification

If a rule does not fit your site — a newsroom where 03:00 logins are normal, say — the base severity map is filterable. See hooks and filters for whochita_base_severity_map.