Attacks Noticed Too Late: Detection Time per Signal

What the Bitkom study says about late detection

For the study, Bitkom Research surveyed 1,003 companies in Germany with 10 or more employees (Bitkom). 58 percent of them suffered damage from cyberattacks in the past twelve months (Bitkom). These 580 companies were asked which factors contributed significantly to the attack succeeding, with multiple answers allowed (Bitkom).

At the top, at 59 percent, is insufficient detection of security incidents (Bitkom). Close behind are misconfigurations of IT systems at 57 percent and insufficient identity and access management at 55 percent (Bitkom). Technical vulnerabilities are named by 50 percent, outdated hardware or software by 43 percent (Bitkom). Insufficient security awareness among employees, by contrast, is cited by only 18 percent (Bitkom).

The second figure carries almost more weight, even though it is broader: it covers data theft, industrial espionage or sabotage as a whole, conventional as well as digital. Only 67 percent of companies were able to establish a successful attack with certainty, compared with 87 percent a year earlier (Bitkom). The share of those who suspect an attack but cannot prove it rose from 10 to 29 percent over the same period (Bitkom). In total, 96 percent of companies were affected or presumably affected (Bitkom). The shift therefore lies less in the number of attacks than in how certain companies are about them.

The most common causes of damage are not particularly sophisticated or exotic attacks, but blind spots in one’s own systems. Anyone who does not reliably detect incidents cannot act in time and may in the end not even be able to say with certainty what actually happened

— Dr. Wintergerst, President of Bitkom, press release of August 26, 2026 (translated)

Detection time: check interval plus the path to a person

A manipulation of a website does not report itself. The time from the change to the moment a person knows about it consists of four parts. Each can be measured and shortened on its own:

1. Wait until the next check. In the worst case the change happens right after a check and sits for a full interval, on average for half of one.
2. Evaluation. The check has to classify the change as suspicious. A hash comparison decides immediately, an image comparison with a learning phase only after a few runs.
3. Delivery. A changelog entry is not yet an alert. Only a notification through a channel someone reads turns the finding into a message.
4. Response. Someone has to read the message, assess it and act, at night and on weekends as well.

The first part appears in the feature description of the tool. The other three depend on your own organization: on the channels under alerting and notifications, on on-call duty and on who reads changelog entries. For outages, this calculation is laid out in the article on the uptime check interval. For manipulations it is stricter, because no visitor complains about an unreachable page.

Why manipulations are quieter than outages

An outage gets noticed, at the latest when orders stop coming in. A manipulation is designed not to be noticed. A skimming script reads card and address data while the payment process continues as usual. A changed DNS record initially redirects only part of the requests, depending on which resolver still holds the old value in its cache. A certificate for a look-alike domain does not touch your own website at all; it prepares the phishing site next to it.

On top of that, many traces are only read after the fact. Companies that were able to identify the perpetrators or origin of an attack most often relied on the analysis of log files, named by 68 percent (Bitkom). Logs help with the investigation. Detection during operation, by contrast, needs checks that know a target state and report a deviation before anyone goes looking for it.

A website offers several independent points to check: embedded scripts, appearance and markup, security headers, DNS and registration data, and publicly logged certificates. Each is checked at a different interval and sees a different kind of manipulation.

The signals at a glance: what each check sees

The table orders the website-level signals by the interval at which XICTRAQ® checks them according to its feature pages (XICTRAQ®). Each row shows the longest wait until the next check on paid plans; the Free plan has longer intervals. Delivery and response come on top in every row.

Script hash: the fastest signal for skimming

Web skimming modifies an embedded script so that it reads input in the browser and sends it to a foreign server. Because the content of the file changes, its hash changes too. During a scan of a verified website, script integrity monitoring learns the SHA-256 hashes of the external third-party scripts as a baseline, up to 12 per scan, together with host, size and context (XICTRAQ®). Every ten minutes a check run fetches the monitored scripts again, up to 150 per run and the ones checked longest ago first (XICTRAQ®).

If the hash differs, XICTRAQ® reports the drift once per entry through the configured channels until someone acknowledges it or stops monitoring the entry. After a planned update, the immediate check fetches the scripts of a website again without waiting, so a legitimate change can be acknowledged as the new baseline right away. The order matters: first look at the script content, then acknowledge. An acknowledged drift counts as the target state from then on.

For merchants that accept cards, the topic is not new. With requirements 6.4.3 and 11.6.1, the card industry standard PCI DSS requires that scripts on payment pages are authorized, checked for integrity and monitored for tampering. Both requirements have been in effect since March 31, 2025 (PCI SSC). Which check frequency applies in a given case and whether a solution meets the requirement is something merchants clarify with their acquirer or assessor. A monitoring tool supplies measurements for this, but no confirmation of compliance.

Detecting new embeds and visible changes

An attacker does not have to modify an existing script. They can add a new line to the template that loads code from a foreign host, or place a banner over the home page. The ten-minute run sees neither, because it only fetches known scripts again. This is where page comparison comes in. The screenshot changelog captures pages every 24 hours (free) or every 12 hours (paid), depending on the plan (XICTRAQ®); visual diff and defacement detection are available from the Starter plan.

Defacement detection combines three layers into a score from 0 to 100: the pixel comparison with the baseline, a hash of the cleaned HTML and a fingerprint of the DOM structure that captures newly added external script and iframe hosts (XICTRAQ®). The first three runs form the baseline and do not trigger an alert (XICTRAQ®). From a score of 60, XICTRAQ® creates an event and sends an alert; if the score falls below 30 in the following run, the event closes again (XICTRAQ®). Detection is switched on per website.

For detection time, this means: a new foreign embed or a visible defacement usually shows up with the next screenshot run, so on paid plans after at most twelve hours plus delivery. Independently of the score, the image comparison reports large deviations above 20 percent immediately (XICTRAQ®). So that sliders and lazy-loading images do not keep triggering it, XICTRAQ® usually captures a page a second time after 15 seconds when it deviates by more than 3.5 percent (XICTRAQ®).

How a defacement is carried out technically and when it has to be reported under NIS2 is described in the article on defacement attacks. Which other unauthorized content changes exist is covered in the article on detecting content changes.

DNS, registrar and certificates: signals outside the page

Some attacks do not change the website at all. Whoever redirects the DNS record of the domain sends visitors to another server while your own keeps running unchanged. DNS monitoring checks the records every 6 hours, every 24 hours on the Free plan, and records changes to A, AAAA, MX, NS and TXT with old and new value in the changelog (XICTRAQ®). Changes to A, AAAA and NS are marked as a warning there, because they can indicate DNS hijacking. A changed CAA restriction is additionally reported by XICTRAQ® as an alert.

This difference is decisive for detection time. An entry in the changelog has been recorded, but not yet noticed. Anyone who wants to see DNS changes promptly needs a fixed review of the changelog, for example every morning at the same time, and a list of the people who are allowed to change records in the zone. How hijacking works and which countermeasures apply at the registrar and in the zone is explained in the article on DNS hijacking.

XICTRAQ® queries the registry record once a day via RDAP (XICTRAQ®). A registrar change appears as a warning in the changelog, because it can indicate an unauthorized transfer. From the Business plan, the Certificate Transparency watch compares newly issued certificates daily against the brand, look-alike variants and brand keywords (XICTRAQ®). Such a certificate often appears before the look-alike domain even resolves in DNS. Why this works is explained in the article on Certificate Transparency logs.

Misconfiguration and vulnerabilities: drift in the configuration

Misconfigurations rank second among the damage factors in the Bitkom study at 57 percent (Bitkom). At website level, such drift often shows in the security headers: after an update the Content Security Policy is missing, an upstream proxy strips HSTS, a plugin resets frame protection. The security scan checks the certificate and security headers every 6 hours on paid plans and every 24 hours on the Free plan (XICTRAQ®). If the security score drops below the configured minimum, an alert is sent; the default is 50 (XICTRAQ®).

The number of vulnerabilities that become known has risen as well. In the reporting period of the BSI situation report 2025, an average of 119 new vulnerabilities in IT systems became known every day (BSI), around 24 percent more than in the previous reporting period (BSI); the BSI attributes part of the increase to a changed reporting policy. For detection, this means that a configuration that looked unremarkable yesterday can be an open door today without anything having changed on the website itself.

A single header finding is rarely the attack itself, but it shifts detection time elsewhere. A Content Security Policy with a reporting address lets visitor browsers report when a resource is about to be loaded from a host that is not allowed, and XICTRAQ® collects these reports per website. Without the policy, this signal disappears entirely. Anyone who wants to lock in HSTS permanently should first read the notes on HSTS preload.

What none of these checks can see

Checks from the outside see what the website delivers and what is in DNS. What lies behind it stays invisible. This is not a shortcoming of individual features but the limit of the approach, and it belongs in every plan for detection time:

• Files on the server. A backdoor in the file system that does not change the output is invisible to any external check. XICTRAQ® does not perform malware analysis at file level; that belongs on the server itself, for example as a responsibility of the hosting provider.
• Access and accounts. A new administrator account in the CMS or a stolen password does not change the page at first. Insufficient identity and access management is named as a factor by 55 percent of companies that suffered damage (Bitkom). Login logs and a dated list of accounts help here.
• Conditional delivery. Malicious code that only appears for certain visitors, from certain countries or only on the first visit can escape a check request.
• Your own script files. Files from your own host are not part of the hash comparison of script integrity. Page comparison only notices them if they change the markup, DOM or image of the page.
• Flows behind the click. A manipulated checkout flow often only shows during the flow itself. That is what browser checks are for; they walk through a path step by step.

Reporting deadlines only start with awareness

Detection time also has a legal side. If a personal data breach has occurred, for example because a skimming script captured address and payment data, the controller notifies the competent supervisory authority without undue delay and, where feasible, within 72 hours after having become aware of it, unless the breach is unlikely to result in a risk to the people affected (GDPR Art. 33).

For essential and important entities under the German BSI Act, significant security incidents trigger three reports with fixed deadlines: an early warning no later than 24 hours after becoming aware (BSIG Section 32), a notification no later than 72 hours (BSIG Section 32) and a final report no later than one month after that notification (BSIG Section 32). If the incident is still ongoing when the final report is due, a progress report takes its place at first and the final report follows once handling is complete; if the BSI requests it, an interim report is added.

Both deadlines run from awareness, not from the attack. Late detection therefore does not extend the time for reporting; it extends the time in which the damage grows unnoticed: every hour between manipulation and alert is an hour in which a skimmer can keep reading along. Whether a specific incident must be reported depends on the individual case and belongs with the data protection officer or legal counsel. What escalation levels and responsibilities look like in an emergency is described in the article on incident management and escalation.

Setting detection time per signal: a worksheet

The building blocks add up to a table per website: how long a manipulation can wait until the next check at most and what happens after that. Seven steps lead there:

1. Define what to protect. Checkout and form pages, home page, DNS zone, domain registration, brand.
2. Assign a signal. For each asset, the check that sees a manipulation there first: script hash for the checkout, defacement score for the home page, DNS and RDAP check for zone and registration, Certificate Transparency watch for the brand.
3. Enter the check interval. The longest wait according to the plan, not the most favorable case.
4. Check the notification path. Alert through a channel or just an entry in the changelog? Agree on a fixed review for changelog entries.
5. Agree on response times. Who responds on weekdays, who at night, and by when.
6. Name the gaps. Whatever no check covers gets an owner outside of monitoring.
7. Practice. Trigger a real alert regularly and measure when it was read.

website: shop.example.invalid
as_of: 2026-10-30
signals:
  - asset: Checkout
    signal: Hash of external scripts
    interval: 10 min
    notification: Alert via email and chat
    response: 30 min on weekdays, 2 h at night
  - asset: Home page
    signal: Defacement score
    interval: 12 h
    notification: Alert from score 60
    response: 2 h
  - asset: DNS zone
    signal: Change to A, AAAA, NS
    interval: 6 h
    notification: Warning in the changelog
    review: weekdays 9 am
  - asset: Brand
    signal: Certificate Transparency watch
    interval: 24 h
    notification: Match in the dashboard
no_signal:
  - Files on the server: hosting provider, weekly integrity check
  - CMS accounts: agency, account list on the first of the month

For a shop on the Business plan, this means: at the checkout, the wait until the next script check is at most ten minutes, on the home page at most twelve hours, in DNS at most six hours plus the time until the next review of the changelog (XICTRAQ®). Whether the chain holds after that only a test can show. How such an alerting drill is set up is described in a separate article.

From signal to response

An alert only shortens detection time if it is clear what happens next. A short sequence that stays the same for every signal has proven useful:

Making detection time an operational metric

The Bitkom figures show that companies fail less because of exotic attacks than because of incidents they notice too late or not at all. Anyone who knows the detection time per signal for each website can shorten it where it matters: the check interval where it counts, the notification path where a changelog entry sits unread, and the response where nobody can be reached at night. Which check intervals each plan includes is listed on the pricing page.