Audit Log Anomalies Analyzer

A password failure at 02:00 can be an attack, a stale job, or an administrator working through a planned maintenance window. Audit-log review turns that ambiguous event into a better question by connecting time, identity, action, source, outcome, and target.

Logs from identity systems, cloud control planes, operating systems, and applications often describe the same facts with different field names. One product records a principal and event name, another records a user and operation, and a third may provide only a timestamp, source address, and message. Normalizing those fields makes cross-source triage possible, but it cannot restore context that was never logged.

An anomaly is a review lead, not a verdict. Root activity, repeated denials, a new source, or an after-hours action deserves attention because it can be consequential, yet each can also have an approved explanation. Confidence comes from matching the event to change records, identity ownership, authentication evidence, network context, and nearby activity.

Completeness matters as much as ranking. Missing time zones prevent reliable after-hours checks, missing sources weaken trust comparisons, and a narrow export may hide the earlier event that explains a source shift. Preserve the original log evidence and use automated ranking to decide what to inspect first.

How to Use This Tool:

Start with a focused export that still contains the fields and neighboring events needed to explain suspicious activity.

1. Paste or load CSV, JSON, JSON Lines, or AWS CloudTrail data. Keep Auto detect unless the structure is ambiguous; the resolved format confirms what was parsed.
2. Enter trusted IPv4 addresses, IPv4 CIDR ranges, or source-text fragments. Leave the list empty when unfamiliar-source signals should be disabled.
3. Set expected active hours and the failed-event count and time window that define a burst. Use the timezone already present in each timestamp.
4. Add environment-specific privilege or failure terms only when the built-in vocabulary misses real actions. Review rejected-row warnings before trusting the ranking.
5. Open the highest-risk Review queue rows, then use Signal findings to gather related actors and sources for investigation.

Interpreting Results:

Risk is an additive triage score. A high number means one row matched several configured signals or a heavily weighted signal; it does not estimate breach probability. Highest severity is simply the most severe matched signal, so two rows with the same severity can have different scores.

• Investigate root or administrator identities and privilege-changing actions first, especially when they also come from an unfamiliar source.
• Treat a failure burst as a cluster for the same actor and source, not as proof of credential guessing.
• Check rejected rows and missing fields. A clean queue based on incomplete parsing is weak evidence.
• Correlate a finding with MFA, VPN, change-ticket, endpoint, and application logs before deciding that activity is malicious.

Technical Details:

Audit triage follows a transparent transformation: parse the source, map common field aliases into a shared event shape, evaluate each configured signal, add its weight, and sort rows by descending risk. Every accepted event remains in scoring even when the displayed review queue is shortened.

Transformation Core

1. CSV, JSON, JSON Lines, and CloudTrail-shaped records are reduced to time, actor, action, source, outcome, target, and identity type.
2. Privilege terms are matched against action plus target; failure terms are matched against outcome plus action.
3. Source trust, active hours, actor-source changes, source concentration, and failure bursts are evaluated from the normalized slice.
4. Matched signals produce event scores, per-signal totals, and a review order. Rows with equal risk retain their source order.

Rule Core

The signal weights are local triage rules, not values from a security standard. Several rules may apply to the same event.

Active-hour ranges include the start hour and exclude the end hour. An overnight range wraps across midnight, while equal start and end values allow every hour. Events without a usable timestamp cannot trigger the time-window burst rule or a reliable after-hours rule.

Formula Core

An event's score is the sum of the fixed weights for all signals that matched that event.

M_e is the set of signals matched by event e, and w_k is each signal's weight. The overall risk score adds the event scores across the accepted source slice; no normalization or probability conversion is applied.

Limitations and Privacy Notes:

Keyword matches can miss unfamiliar event vocabulary and can flag harmless strings. Trusted-source checks support IPv4 CIDR, exact IPv4, and text fragments; they do not interpret IPv6 CIDR, geolocation, device identity, or proxy chains. Source-shift and concentration findings depend only on the supplied slice.

• Log text and selected files are analyzed in the browser rather than uploaded for analysis.
• Audit exports can contain identities, addresses, resource names, and security-sensitive actions. Redact secrets and minimize the slice before sharing results.
• The score supports triage only. Preserve original records and follow the organization's incident-response and evidence-handling procedures.

Worked Examples:

References:

• Guide to Computer Security Log Management, National Institute of Standards and Technology, September 2006.
• Understanding CloudTrail events, Amazon Web Services.
• How to view sudo logs, Simplified Guide.