CyberTI Research · August 2026

CyberTI threat signal snapshot: 3 September 2026

An anonymized 30-day snapshot of signals, indicators, alerts, and phishing candidates processed by CyberTI, compared against the July edition, with methodology and limitations.

This privacy-safe snapshot describes what CyberTI processed during the 30 days ending 3 September 2026. It measures platform records—not attacks, victims, incidents, or unique threat campaigns. It is the second edition, which makes it the first one with something to compare against, and most of what changed says more about the platform than about the world.

Executive summary

219Collected items from 14 contributing sources
795Extracted IOC occurrences
724Alert records created
931Phishing candidates first seen in-window

At the snapshot time the deployment had 18 configured sources, of which 12 were active: 5 forum, 5 web, and 2 Telegram. Source status represents operational configuration, not a judgment of source quality — a source can be inactive because it was retired, because access broke, or because it was deliberately paused.

What changed since the July edition

Comparison with the 30 days ending 24 July 2026
MeasureJulyAugustChange
Collected items225219−2.7%
Contributing sources1314+1
IOC occurrences1,444795−44.9%
Distinct type-value pairs1,239606−51.1%
Alert records912724−20.6%
Item-to-asset matches268213−20.5%
Phishing candidates1,227931−24.1%
Candidate-to-asset matches2,3601,824−22.7%

The 45% fall in extracted indicators looks alarming next to an item count that barely moved, so we went looking for it. It is a tail effect, and the mean was hiding that:

Indicator extraction per collected item
MeasureJulyAugust
Items yielding at least one indicator133 of 225 (59.1%)124 of 219 (56.6%)
Median indicators per such item1.01.0
Mean indicators per such item10.96.4
Largest single item501136
Five largest items1,007 (69.7% of total)445 (56.0%)
Total excluding the five largest437350

The median item produced exactly one indicator in both windows, and the share of items producing any indicator at all was effectively unchanged at 59.1% and 56.6%. Nothing about extraction changed. What changed is the tail: July contained a single item carrying 501 indicators — most likely a bulk list posted in one place — and its five largest items accounted for 69.7% of the entire month, against 56.0% in August.

Strip the tail and the headline number dissolves. Excluding the largest item from each window, the fall is 30.1% rather than 44.9%; excluding the five largest, it is 19.9% — the same order as the 20.6% fall in alert records and the 20.5% fall in item-to-asset matches. The underlying change is a modest, consistent decline across every population, and the extra 25 points on the indicator line are one post.

This is worth stating plainly because it is the failure mode of monthly reporting in this field. Indicator counts are heavy-tailed: a handful of posts dominate any given month, so a mean is close to meaningless and a month-over-month change in the total mostly measures whether someone happened to dump a large list. The median is the honest statistic here, and by that measure the two windows are identical.

Collected signals and indicators

The 219 collected items came from 14 distinct contributing sources and produced 795 extracted IOC occurrences across 606 distinct type-value pairs.

Extracted IOC occurrences by type, with the previous edition for comparison
IOC typeAugustJuly
Email387314
URL101418
MD597196
Domain9136
Telegram handle5432
IPv428411
Telegram URL2417
FQDN815
Other (SHA-256, BTC wallet, onion URL)55

The composition moved further than the total. Email addresses went from roughly a fifth of occurrences to nearly half, while IPv4 addresses fell from 411 to 28 and URLs from 418 to 101. This is the same tail effect seen above, viewed by type: one bulk item of 501 indicators sets a month's type distribution by itself. The type mix therefore describes what a few posts happened to contain, not what is prevalent — and it is not a measure that should be trended.

Alert distribution

Alert records by severity or queue label
LabelRecordsShareJuly share
High51370.9%75.9%
Medium15922.0%17.7%
Review385.2%4.9%
Low141.9%1.5%

Of the 724 alert records, 722 remained in the analyst state new at snapshot time and 2 were marked false positive. That distribution is not a claim about accuracy: unreviewed is the default state, so a high proportion of new reflects review pace and retention rather than a verdict on the alerts. The item population also produced 213 item-to-asset match records.

Phishing-candidate pipeline

The separate phishing cohort contained 931 candidates first seen during the window. Automated checks found 894 resolving in DNS (96.0%), 793 reachable over HTTP (85.2%), and 605 with active TLS (65.0%). The same cohort produced 1,824 candidate-to-asset match records.

Active TLS fell from 78.1% to 65.0% between editions. Two readings are available and we cannot separate them from these numbers alone: the cohort may contain more candidates observed very soon after registration, before a certificate exists, or the checking behaved differently. We report the change and decline to explain it.

Phishing candidates by recorded severity
SeverityCandidatesShareJuly share
Suspicious36339.0%17.0%
Confirmed34136.6%25.3%
High22023.6%17.1%
Info70.8%40.6%

This table is the clearest example of why edition-to-edition comparison has to be read carefully. The info band went from the largest group to almost nothing. Nothing about phishing changed that much in five weeks. The scoring and triage behaviour behind these labels was revised during the window, so the labels do not mean precisely what they meant in July, and the two distributions are not measuring the same thing.

The cohort also carries triage lanes that did not exist in the previous edition: 418 candidates sat in a ready-for-review state, 220 in a lane for domains whose registration history is long enough to make impersonation unlikely, 214 newly created, and 76 parked in a lane for bulk commercial domain abuse that does not target a specific brand. Those lanes exist to keep the confirmed queue small enough to be worked, which is a design choice rather than an observation.

How to read a second edition

A single snapshot cannot be over-interpreted because there is nothing to compare it to. A second one is more dangerous, because two numbers form a line and a line invites a story. Two of the largest movements above turned out to have mundane explanations once we looked: the indicator drop is one outsized item in the previous window, and the severity redistribution is a scoring change on our side.

Looking is the point. A caveat is not a substitute for checking, and "this may reflect methodology" is what a report says when nobody went and found out. Where we did find out, it is above; where we could not, we say so rather than reaching for a trend.

The measures worth watching across future editions are the ones least sensitive both to our configuration and to the tail — collected items, contributing sources, and medians rather than totals. Even those describe one deployment's coverage rather than the internet.

The previous edition is available as the July 2026 snapshot. Where the two disagree, the July definitions are the ones that changed.

Methodology and limitations

  • Window: records from 4 August 2026 12:45 UTC through a database snapshot at 3 September 2026 12:45 UTC — a rolling 30 days, not a calendar month.
  • Access: read-only SQL aggregation against production tables. No production writes were made.
  • Privacy: no raw IOC value, source name, customer identifier, domain, matched term, message content, or analyst identity was extracted for publication.
  • Populations: collected items, alerts, and phishing candidates are separate processing populations. Their totals must not be added together.
  • IOC counting: an occurrence is an extracted row; the distinct count deduplicates type-value pairs within the window.
  • Phishing cohort: candidates are included by their first-seen timestamp. Asset-match counts use that same candidate cohort.
  • Comparability: the July window ended 24 July 2026 and used the same definitions, but the scoring and triage behaviour behind severity labels changed between editions. Severity comparisons are indicative only.
  • Coverage gap: the July window closed on 24 July and this one opens on 4 August, so 25 July to 3 August falls in neither edition. Editions are rolling 30-day windows anchored to their publication date and do not tile; totals from consecutive editions cannot be added to describe a longer period.
  • Heavy tails: indicator counts per item are dominated by a small number of bulk postings. Medians and the share of items producing any indicator are reported alongside totals, and should be preferred when comparing editions.
  • Interpretation: these are processing records, not estimates of attacks, victims, incidents, prevalence, or unique campaigns.
  • Snapshot: statuses can change after the snapshot as enrichment and analyst review continue.
Reproducibility boundaryThe exact aggregates can be reproduced internally from the stated window and cohort definitions. The underlying records remain private, so external readers cannot independently reconstruct row-level results.