{{ summaryHeading }}
{{ riskScoreDisplay }}
{{ summaryLine }}
{{ riskBadgeText }} {{ parsedEventCountDisplay }} {{ highestSeverityDisplay }} {{ signalCountDisplay }}
Supported CSV columns include timestamp, actor, action, source_ip, result, and target; CloudTrail Records are detected automatically.
{{ sourceMeta }}
{{ sourceFileStatus || 'Drop CSV, JSON, LOG, or TXT onto the textarea.' }}
{{ sourceError }}
Choose a format only when auto-detection guesses the source incorrectly.
Comma or newline separated; external sources are flagged when this list is present.
Use 0-23 hour values; overnight windows such as 22 to 6 are supported.
to
Set the failure count and time window that should be treated as a burst.
failures in min
The default list targets common IAM, role, policy, MFA, and account-management actions.
Tune this when your audit source uses custom words for rejected activity.
Use a higher number for large exports; source repeats are summarized in Source Hotspots.
events
Keep this practical for browser rendering when pasting large log extracts.
rows
Metric Value Audit note Copy
{{ row.metric }} {{ row.value }} {{ row.note }}
Signal Severity Count Risk points Evidence Next action Copy
{{ row.signal }} {{ row.severity }} {{ row.count }} {{ row.score }} {{ row.evidence }} {{ row.nextAction }}
Source Events Actors Failures Privilege events First seen Last seen Copy
{{ row.source }} {{ row.events }} {{ row.actors }} {{ row.failures }} {{ row.privilegeEvents }} {{ row.firstSeen }} {{ row.lastSeen }}
Time Actor Action Source Result Signals Risk points Copy
{{ row.time }} {{ row.actor }} {{ row.action }} {{ row.source }} {{ row.result }} {{ row.signals }} {{ row.risk }}
Tags: Diagnostics, Security
Kubernetes Events Timeline Analyzer Analyze Kubernetes event output in your browser, grouping Warning reasons, object hot spots, repeat counts, and timeline bursts from kubectl text or JSON.
Network Audit Findings Report Turn network audit findings into a sorted remediation register with escalation status, owner queues, evidence gaps, charts, and report wording.
Firewall Deny Log Analyzer Analyze firewall deny logs in your browser, group blocked source-service paths, and prioritize watched ports with CIDR direction checks.
Container Security Scan Analyzer Analyze container scan output in your browser, normalize vulnerability findings, test release gates, and rank fixable packages for remediation.
Customize
Advanced
:

Audit logs are the record that lets a security review move from suspicion to evidence. They show who tried to act, what operation was attempted, where the request appeared to come from, when it happened, what system or object was touched, and whether the request succeeded. A single row rarely tells the whole story, but a set of rows can reveal repeated failures, unusual sources, after-hours administration, and changes to powerful identities.

Useful anomaly review starts with a realistic baseline. A failed login at night may be harmless if the team runs a planned maintenance window, while the same failure near a new access-key change deserves closer attention. A source address may be expected when it is a jump host, proxy, VPN exit, or automation runner. The same source can be suspicious when it has no owner, appears outside the normal administrative path, or shows up next to denied activity.

The vocabulary matters because different audit products use different names for the same facts. Cloud logs may call the operation an event name, web and database logs may call it an action or statement, and identity systems may record a principal, user, actor, or role session. A practical review normalizes those facts before assigning meaning.

Actor
The user, role, service account, root identity, or session name tied to the event.
Action
The operation being attempted, such as a login, role assumption, policy update, access-key change, or permission edit.
Source
The address or client marker that helps separate expected administrative paths from unfamiliar origins.
Outcome
The success, failure, denial, or error clue that explains whether the request was accepted or blocked.
Audit anomaly review path Audit events are normalized into actor, action, time, source, and outcome fields, then signal rules rank the events for review. Event slice CSV, JSON, or cloud records Field map actor action time and source outcome Signal rules failures privilege source shifts after hours Queue risk evidence Anomaly review ranks clues for humans to verify against owners, source records, tickets, and the original log system.

Several patterns deserve review because they often appear around compromise, configuration drift, or weak operational controls. Repeated failures can point to password spraying, stale credentials, or a locked-out automation account. Privilege changes can be legitimate administration, but they also alter the blast radius of a stolen identity. Source shifts can be normal for a roaming user or alarming for an account that should only run from one administrative network.

Scores and labels should stay modest in security language. An anomaly is a clue, not a verdict. Missing fields, clock skew, inconsistent actor names, address translation, and incomplete exports can all change the result. The strongest audit review keeps a clear chain from summarized signal back to the original event rows, then confirms ownership and authorization before declaring an incident.

The main job is triage. A ranked view helps decide which actor, source, and action combinations deserve attention first, while still leaving final judgment to the investigation process, change records, identity owners, and the authoritative logging platform.

How to Use This Tool:

Work from one focused audit slice first. Confirm that rows parse cleanly, then tune trusted sources, hours, and signal thresholds before comparing different exports.

  1. Paste rows into Audit log source, drop a file onto the textarea, or use Browse log for a CSV, JSON, LOG, or TXT file under 2 MB. Use Load sample when you want to see the expected result shape before using your own data.
  2. Choose Input format. Keep Auto-detect for most exports, or select CSV rows, JSON array or object, JSON Lines / NDJSON, or AWS CloudTrail Records when parser warnings show that the source was guessed incorrectly.
    Auto-detect handles headered CSV, timestamp-first CSV rows, JSON arrays, object records, JSON Lines, and CloudTrail-style Records arrays.
  3. Set Trusted sources to expected IPv4 CIDR ranges, exact addresses, or source text fragments. Leave the field empty only when you do not want unfamiliar source checks to affect the score.
  4. Set Expected active hours and Failure burst rule. The hour check uses the hour present in each event timestamp, and overnight windows such as 22 to 6 are supported.
  5. Open Advanced when your environment uses custom action words, denial words, or high-volume sources. Tune Privilege keywords, Failure keywords, Source repeat threshold, and Event ledger rows before relying on the queue.
    Changing keyword lists changes the score for the same log rows. Keep the same settings when comparing two time windows.
  6. Read the summary badges first. escalate now means a Critical signal is present, triage quickly means High severity appeared, review signals means lower-severity evidence exists, and baseline only means no configured anomaly rule fired.
  7. Use Risk Snapshot to check counts, Anomaly Signals to choose the first review path, Source Hotspots to inspect noisy origins, Event Ledger to trace individual rows, Signal Pressure to compare signal weight, and JSON when you need a structured audit envelope.
    If Rejected rows is greater than 0, fix the source format or malformed rows before treating missing actors, sources, or failures as meaningful.

Interpreting Results:

Risk score is a triage number for the current audit slice. It rises when events match weighted signals such as root/admin identity use, failure bursts, privilege-changing actions, unfamiliar sources, source shifts, and after-hours activity. It is not a probability of compromise, and it is not comparable unless the export scope and rule settings stay the same.

Highest severity is often the faster escalation cue. One Critical root/admin row may deserve more attention than many Low after-hours rows. A high source count may be routine when it comes from a proxy, deployment host, or identity broker, but the same count becomes more important when it includes failures or privilege changes.

Result cue Likely reading Verification step
Risk Snapshot has High or Critical severity At least one row matched a high-weight signal such as root/admin identity, a failure burst, or a privilege-changing action. Open Event Ledger and confirm actor, action, source, result, and timestamp in the authoritative log system.
Anomaly Signals lists Failure burst The same actor and source met the configured failure count inside the configured minute window, or met the count by row order when timestamps were missing. Check authentication prompts, account lockouts, multi-factor events, and whether the source belongs to a known administrative path.
Source Hotspots is dominated by one source One source produced many events or risk points in the visible slice. Confirm whether the source is a VPN exit, proxy, automation host, scanner, service endpoint, or shared jump server.
Rejected rows is greater than 0 Some rows were skipped or malformed, so the counts may not represent the full export. Fix the input or select the correct Input format, then rerun the same slice before sharing evidence.

Treat a high score as a prompt for faster human review. Confirm the identity owner, source path, change record, and business reason before labeling activity malicious. Treat a low score with caution when the export is narrow, failure events are missing, or the trusted-source list is incomplete.

Technical Details:

Audit anomaly scoring depends on comparable event fields. CSV, JSON, JSON Lines, and CloudTrail-style records can describe the same security activity with different names for time, actor, action, source, outcome, target, and identity type. The review becomes useful only after those names are mapped into one common event shape.

The scoring model is intentionally transparent. It does not build a statistical baseline or learn normal behavior across an organization. Instead, it marks common review signals that security teams often need to verify: denied activity, repeated failures, privilege-related actions, root/admin identity use, sources outside the trusted list, activity outside expected hours, high source concentration, and actor movement across sources.

Formula Core:

The score is the sum of weighted signals on each event, then summed across the current audit slice.

Re = ∑s∈Sews Rtotal = ∑e∈ERe

Se is the set of signals on one event, ws is the weight for each signal, Re is that event's risk points, and Rtotal is the displayed risk score. A root actor that changes a policy from an unfamiliar source outside expected hours can add +8, +5, +3, and +2 before any burst or source-shift rule is added.

Rule Core:

Signal Condition Weight Severity
Root or admin identity Actor or identity type reads as root or admin. +8 Critical
Failure burst The same actor and source meet the configured failure count within the configured minute window. If usable timestamps are missing, row order is used for the count. +6 High
Privilege-changing action Action or target text matches a configured privilege keyword. +5 High
Untrusted source Source misses every exact IP, CIDR range, and trusted text fragment. Blank, unknown, and service-internal sources are not flagged. +3 Moderate
Actor source shift An actor uses two or more sources and at least one source is untrusted. +3 Moderate
Failed or denied activity Result or action text matches a configured failure keyword. +2 Moderate
After-hours activity Timestamp hour falls outside the expected active-hours window. Missing or unreadable hours are treated as in range. +2 Low
Source concentration A non-unknown source reaches the configured repeat threshold in the current slice. +1 Moderate

Field and Boundary Rules:

Area Accepted or normalized value Effect on results
Input formats Headered CSV, timestamp-first CSV rows, actor/action/time/source rows, JSON array or object, JSON Lines / NDJSON, and CloudTrail-style records. Rows become audit events when enough actor, action, time, source, result, or target fields can be found.
Actor identity Common actor, user, principal, identity, role-session, ARN, and source-identity fields. Controls grouping, source-shift detection, root/admin checks, and event-ledger evidence.
Trusted sources Exact IPv4 address, IPv4 CIDR range, or text fragment. Controls whether a source can trigger Untrusted source and contribute to Actor source shift.
Expected active hours Whole hours from 0 to 23; equal start and end means all hours. Events outside the interval receive After-hours activity. Overnight ranges are evaluated across midnight.
Failure burst rule 2 to 50 failures inside 1 to 1440 minutes. Sets the count and time span needed for Failure burst.
Source repeat threshold 2 to 500 events. Sets when one source receives Source concentration.
Event ledger rows 10 to 2000 rendered rows. Limits the displayed and exported ledger rows. Scoring still uses all parsed events in the current slice.

Repeatability matters. A changed keyword, trusted-source list, work-hours range, source repeat threshold, or export window can change both score and severity without any change in the underlying event stream.

Limitations and Privacy Notes:

Audit rows are parsed in the browser, and pasted or loaded log content is not uploaded for analysis. The generated outputs can still contain sensitive identities, addresses, role names, failure messages, targets, and permission-change evidence, so treat copied tables, chart images, DOCX files, CSV files, and JSON exports as investigation material.

  • The result is a triage aid, not a forensic conclusion, incident declaration, or substitute for the authoritative log platform.
  • The scoring rules are keyword and threshold based. They do not learn an organization's historical baseline, threat model, or approved change calendar.
  • Incomplete exports, missing failure events, clock skew, address translation, shared proxies, and inconsistent actor names can change the score.
  • Redact sensitive rows before sharing exports outside the team that owns the investigation or audit evidence.

Advanced Tips:

  • Keep a saved baseline of Trusted sources, Privilege keywords, and Failure keywords for each environment so recurring reviews use comparable rules.
  • Raise Source repeat threshold for large cloud or identity exports that include normal automation noise, then lower it again for focused incident windows.
  • Use Signal Pressure to spot which signal type is driving the score before reading every row in Event Ledger.
  • Check Rejected rows after every paste or upload. One malformed JSON Lines record does not stop valid rows from appearing, but it can hide evidence from the same time window.
  • Use UTC or a documented local timezone consistently in source exports. Expected active hours reads the timestamp hour as written and does not convert timezones.
  • Download JSON when another reviewer needs the exact settings, metrics, signals, sources, events, and parser warnings that produced the current view.

Worked Examples:

These cases show how the same event slice can change meaning when thresholds, source lists, or parser quality change.

Repeated sign-in failures

A CSV slice has three ConsoleLogin failures for bob from 198.51.100.23 between 02:17 and 02:23. With the default Failure burst rule of three failures in 10 minutes, Anomaly Signals includes Failure burst, and Event Ledger shows the matching rows with High severity points.

Privilege change outside trusted sources

A root row runs AttachUserPolicy from 203.0.113.44, while Trusted sources contains only private administrative ranges. The row can receive Root or admin identity, Privilege-changing action, Untrusted source, and possibly After-hours activity, so Highest severity can become Critical even when the slice has only one event.

Malformed JSON Lines export

A JSON Lines export includes one broken line between valid records. The valid rows still appear, but Rejected rows becomes greater than 0. Fix the broken line or select the correct Input format before using the counts in a report, because the missing line may be part of the same actor or source pattern.

FAQ:

Can it read AWS CloudTrail records?

Yes. Auto-detect can read CloudTrail-style JSON with a Records array, and AWS CloudTrail Records can be selected when auto-detection needs help.

Why did a source not count as untrusted?

A blank, unknown, or service-internal source is treated as expected. Other sources must miss every exact IP, CIDR range, and text fragment in Trusted sources before Untrusted source appears.

Why does the score change after editing keywords?

The privilege and failure checks are text matches. Adding a word can create more Privilege-changing action or Failed or denied activity signals, while removing a word can lower the score for the same records.

What should I do when no events appear?

Check the validation message, confirm the source is not empty, and choose the correct Input format. CSV rows need enough fields to identify an event, and JSON or JSON Lines must parse cleanly.

Does a high score prove an incident?

No. Use Anomaly Signals and Event Ledger to choose what to review first, then confirm the owner, source, change record, and authorization before calling the activity malicious.

Glossary:

Audit event
A recorded action with actor, time, source, outcome, and target context.
Failure burst
Repeated failed or denied activity for the same actor and source within the configured window.
Trusted source
An address, CIDR range, or source marker treated as expected for the current review.
Actor source shift
An actor appearing from multiple sources when at least one source is not trusted.
Source concentration
A source that appears at or above the configured repeat threshold in the current slice.
Privilege-changing action
An action or target that matches configured role, policy, access-key, multi-factor, account, or permission keywords.

References: