Watching Credential Attacks in Your Logs

Every other article in this series builds a control that acts — throttling, banning, allowlisting, key-only auth. This one builds the thing that watches, and without it the others fly blind. You cannot tune a threshold you have never measured against, you cannot tell whether your banning is working, and — most importantly — you cannot distinguish the endless, harmless background guessing that every server receives from the rare, quiet moment when someone has actually decided to come after you. Monitoring is what turns a pile of log lines into that judgment.

The core skill here is separating noise from targeting, and the secret to it is unglamorous: you have to know what normal looks like before you can recognize abnormal. This article shows you how to build a baseline for your own server, set alert thresholds that fire on real signals instead of raw volume, tell scanner weather apart from a targeted campaign, and decide when something has crossed the line into "escalate now."

This is the closing article of our Brute-Force Defense series. It assumes you can already read the attack signatures from the anatomy of credential attacks — monitoring is what you do with that reading skill at scale, continuously, so the one line that matters does not scroll past unseen.

Why Baselines Come First

Here is the mistake almost everyone makes: they set an alert like "page me if there are more than 500 failed logins in an hour," pulled from thin air. On a busy internet-facing server that either pages constantly (because 500 is a slow afternoon of scanner noise) or never (because the number was set too high to ever catch the quiet attack). A raw count carries no meaning on its own.

"Ten thousand failed logins yesterday" is either a catastrophe or a Tuesday, and the only thing that tells you which is your baseline — the measured shape of normal for this server. If your typical day is 9,500 failures of ambient scanning, then 10,000 is unremarkable weather. If your typical day is 50, then 10,000 is a five-alarm event. Same number, opposite meanings, and the baseline is the difference. So the first task in monitoring is not to set thresholds; it is to measure normal for long enough that you know what normal is.

What to Baseline

A useful baseline is a handful of metrics, each measured over that month, so you know both the typical value and how much it naturally swings. These are the ones that earn their keep:

• Failed logins per hour and per day. The headline volume, and its daily rhythm — most servers have a scanner-noise floor that rises and falls in a recognizable pattern.
• Distinct source addresses per day. How many different places the noise comes from normally.
• Distinct accounts targeted per day. Ambient scanning hits a predictable set of guess-list names; a jump here can mean someone is working through your real accounts.
• Failures per source. The distribution matters more than the average — normally most sources fail once or twice and a few fail a lot. The shape is what you are learning.
• Distinct accounts failed against per source. The spray detector. Normally near one; a single source failing against many different valid accounts is the fingerprint of a spray.
• Successes following a failure streak. This should baseline at essentially zero. It is the most important metric precisely because its normal value is "never."
• Protocol and off-hours distribution. Which interfaces see the noise, and how attempts split between business hours and the quiet middle of the night.

None of this requires heavy tooling to start — a scheduled query over your collected logs, summarized weekly, builds the baseline perfectly well. The prerequisite is that the logs are actually collected somewhere searchable, which is the job of our transfer logging and audit series. A server such as Sysax Multi Server records the per-attempt authentication events — account, source, protocol, outcome — that every one of these metrics is computed from.

One caution while you measure: a baseline captured during an attack bakes the attack into "normal." If a campaign happens to be running through your whole baseline window, you will set your thresholds above it and go blind to that exact behavior forever. Sanity-check the month you measured — a sudden sustained jump partway through, or a level that looks nothing like the weeks around it, means you should re-baseline on a quieter period.

Watch Successes, Not Only Failures

It is easy to fixate on failed logins because they are where attacks are loud, but the events that actually matter are successes — and monitoring only the failure side leaves the prize unwatched. Baseline the normal shape of success, too: which accounts log in, from which sources, at what hours, moving roughly how much data. Then the anomalies announce themselves. A service account that has connected from one partner address for years suddenly succeeding from a new country, a dormant account waking up at 3 a.m., or a login immediately followed by a far larger download than that account has ever made — none of these are failures, so a failure-only monitor never sees them, yet each is a stronger signal of a real problem than any amount of ambient guessing. The single most important alert in this whole series, the success after a failure streak, lives precisely at the seam between the two: it is a success that only means something because of the failures before it.

Scanner Noise vs Targeting

With a baseline in hand, you can finally make the judgment that matters: is this the weather, or is this someone deciding on you? The two look different across several dimensions, and no single signal is proof — it is the combination that tells the story.

The tells that flip your read from noise to targeting are worth memorizing, because they are the moments to pay attention: your real account names start appearing in the failures instead of guess-list junk; the same specific accounts get worked repeatedly across several days; the traffic keeps adapting after a ban, returning from new addresses against the same targets; and, above all, a success appears after a run of failures. Any one of these is a reason to look closer. Together they are a campaign.

Alert Thresholds That Fire on Signal, Not Volume

Raw volume makes a terrible alert — it would page you nightly for events that need no human and train you to ignore the pager. Good alerts are rare and meaningful, tuned to patterns rather than counts. The shortlist that earns a real-time alert:

• A success after a failure streak. The single most important alert you will ever set: an account succeeds after ten or more recent failures. Its baseline is zero, so any occurrence is worth a human immediately — this is what a cracked password looks like.
• A service or partner account from a new source. These accounts connect from the same addresses for years. A first-ever source is either an undocumented change or a stolen credential in use.
• Spray shape. One source failing against five or more distinct valid accounts in an hour — invisible to per-account rules, obvious to a per-source count.
• Any lockout or ban of a partner or service account. Whatever the cause, files have likely stopped moving; someone should know before the partner calls.
• Admin-interface failures — all of them. If the console is properly restricted, its baseline is near zero, so every failure is high-signal and cheap to watch.
• A volume anomaly relative to baseline. Not "more than 500," but "several times the normal you measured" — the only volume alert worth having, and only because you did the baselining first.

Everything below that bar — the nightly guess-list noise, the routine bans, the honest typos — belongs in a weekly review digest, not a page. This is not laziness; it is survival. Alert fatigue is how real alerts die: every alert a human learns to ignore trains them to ignore the next one, including the one that mattered. Turning these patterns into fired notifications is the pipeline work in transfer logging and audit.

The Baseline and Alert Worksheet

Pulling it together, here is a worksheet to fill in for your own server. Measure the baseline column first over a month, then set each alert relative to what you measured. Copy it, complete it, and keep it with your runbooks — it is the difference between monitoring you designed and thresholds you guessed.

AUTH-ATTACK BASELINE + ALERT WORKSHEET
Measure "normal" over ~30 days, THEN set thresholds above it.

  METRIC                            | YOUR BASELINE | ALERT WHEN         | ACTION
  ----------------------------------+---------------+--------------------+-----------------
  Failed logins / day (total)       | ______        | > ~3x baseline     | same-day review
  Distinct source IPs / day         | ______        | > ~3x baseline     | review
  Distinct accounts hit / day       | ______        | sudden spike       | review
  Max failures, one source, / hour  | ______        | > ban threshold    | auto-handled
  Distinct accounts per source / hr | ~1            | >= 5 (spray shape) | ALERT
  Success after >=10 fails on acct  | 0             | any occurrence     | ESCALATE now
  Service/partner acct, new source  | known list    | any new source     | ALERT
  Admin-interface failures / day    | ~0            | any                | ALERT
  Off-hours admin login             | none          | any                | ESCALATE
  Real account names in failures    | rare/none     | sustained presence | investigate
  Repeat offense vs YOUR accounts   | ______        | persists > 24h     | ESCALATE
    from rotating new sources        |               |  (= targeting)     |

RULES:
  * Fill the BASELINE column first. A threshold without a
    baseline is a guess.
  * Anything below ALERT level -> weekly digest, never a page.
  * ESCALATE rows mean a human acts now, not at next review.

When an Attack Deserves Escalation

Not every attack is an incident. Most are weather you log and forget. A monitoring practice needs a clear ladder so the response matches the reality, and so the word "attack" does not trigger a fire drill every night.

1. Routine noise — log only. Guess-list scanning, banned sources, honest typos. No human action; it feeds the baseline and the weekly digest.
2. Notable — weekly review. A new pattern, a modest volume bump, a source that got persistent then quit. Worth a human's eyes once a week, not tonight.
3. Alert — someone looks within hours. The spray shape, a partner account from a new source, an unexpected lockout. A person confirms whether it is benign before the trail cools.
4. Incident — someone acts now. A success after a failure streak, off-hours admin activity, or a persistent campaign against your real accounts that keeps returning from new addresses after bans. This is targeting or a possible compromise, and it triggers your response process — which, for a credential in question, may mean the emergency revocation drill from the transfer authentication series rather than a wait-and-see.

The clearest escalation trigger of all is evidence that guessing worked or that someone is persistently targeting your named accounts. Ambient noise never earns an incident; a success that follows failures, or a campaign that keeps coming back from fresh addresses aimed at the same real accounts, always does. When you find yourself unsure, the reading discipline from diagnosing log-driven problems applies here too: gather the lines, count by source and account, and let the pattern — not the panic — decide.

Monitoring Closes the Loop

The reason monitoring is the last article is that it feeds all the others. What you learn watching the logs is exactly what tunes the rest of the stack. A source that keeps evading bans tells you to tighten the auto-ban thresholds. A partner account taking constant fire tells you to put it behind an allowlist. A steady drumbeat of password guessing against an account that could use keys tells you it is time to end password auth for it. And watching the failure noise collapse after you make those changes is how you confirm they worked. Monitoring is not a separate activity from defense; it is the feedback that makes defense adaptive instead of static.

You do not need an expensive platform to begin. A small team gets remarkably far with logs shipped to one searchable place, a scheduled query that builds the baseline and the weekly digest, and a short list of pattern alerts wired to email or chat. Start there, learn your server's normal, and add sophistication only where the baseline shows you need it.

Wrapping Up the Series

Monitoring credential attacks comes down to one discipline: know your normal, then watch for the specific ways attention turns from ambient to aimed. Baseline the metrics that matter over a full cycle before setting a single threshold. Alert on rare, meaningful patterns — above all a success after a streak of failures — and send everything else to a weekly digest so your real alerts keep their meaning. Separate scanner weather from targeting by watching for your real account names, persistence across days, adaptation after bans, and any sign that guessing succeeded. And escalate on evidence of success or sustained targeting, not on volume.

That closes the loop on this series. The anatomy of credential attacks taught the signatures; lockout and throttling and auto-banning act on the loud attacks; allowlisting and key-only authentication remove whole classes of them by design; and monitoring is the watchtower that tells you which layer to reach for next. Together they turn an internet-facing transfer server from a soft target into a boring one.

Frequently Asked Questions