Switch back to the standard briefing

FLUX FLEET — INTEL BRIEFING №72 — PLAIN LANGUAGE

Period: 2026-11-03 07:32 – 2026-11-04 07:33 UTC (24h, day 70 of operations)
Technical version: /data/flux-logs/reports/flux-fleet-intel-briefing-2026-11-04.md

What happened (plain)

Someone used a stolen honeypot login to try to reach Amazon's AI service (Bedrock) for the first time. The attacker, 152.89.244.89, first stole the credential from our canary-farm-1 honeypot, then tried to use it from the same address. AWS blocked every real attempt: 4 identity checks succeeded, and 10 stronger calls failed, including 5 tries to invoke an AI model.

A different attacker re-ran an old attack at record size. The address 34.78.138.84, hosted by Google in Belgium, sent 10,000 fake WordPress login requests to lauterbourg-01-ts in 4 minutes. That one run is why lauterbourg-01-ts saw 324% more traffic than its weekly average.

A third attacker ran the widest scanning list we have ever recorded for this kind of scan: 195.178.110.247 (Techoff Srv, Bulgaria) tried 6,709 different file paths on canary-farm-1 in 33 minutes. Most were HEAD requests for JavaScript source-map files. It got nothing: every fake path returned 404 or was slowed by our tarpit.

The rest was quieter. The old mass dictionary attack (MEGA-DICTIONARY) did not run this window, so frantech-ts traffic fell 97% to 517 events. We minted 67 new canary credentials to 41 attacker addresses and saw only the one Bedrock attempt. Nothing changed in the fleet itself.

What it means (plain)

  1. Attackers now point stolen honeypot logins at AI services, not just at AWS servers. In one 14-call session, 152.89.244.89 confirmed who it was 4 times and then failed 10 times trying to read more: 5 tries to run an AI model (InvokeModel), 1 try to list AI models (ListFoundationModels), plus single tries at SSM, EC2, and IAM. (High confidence on what happened — the Tracebit alert logs record each call and its result. Moderate confidence on where this goes — it is one session from one address, and attackers tried Bedrock once before (briefing №67) and were blocked then too.)
  2. The WordPress attack kit travels on its own; operators just rent it. 34.78.138.84 copied briefing №67's attack exactly: 10,000 login POSTs, 5 paths, and the same fake browser string (Chrome/89.0.4389.114). Different node, different address, identical kit. (High confidence — we checked the request bodies and headers directly.)
  3. Scan lists keep getting wider, but our decoys give nothing back. 6,709 paths is a fleet record for a config census (the old record was AI-CLI-VAULT's 1,438 paths). Techoff's four legs took 0 credentials, because every bait 404'd or stalled. (High confidence on the counts; Moderate on the trend — that is one window from one operator.)
  4. Stolen credentials are piling up unused; only the attacker who stole them used one. 66 of the window's 67 stolen canary logins drew no AWS activity at all. The big hoarder, SI-CENSUS (56 credentials in 6 days), used none. (High confidence on the counts; Moderate on the hoard reading — past briefings show attackers can wait a day or more before using a credential.)

Campaigns (who / what / what it means)

CREDENTIAL-DRAIN — stolen honeypot logins being cashed in AWS

  • Who: 41 attacker addresses collected 67 canary credentials this window (the digest counted 83 mint rows: canary-farm-1 32, ai-devbox-1 28, control-1 12, ru-edge-1 11; the difference is how each system counts the same day). One address, 152.89.244.89, used a credential it stole itself. Old stockpiles still sit unused: SI-CENSUS holds 56 credentials over 6 days, 34.95.21.228 holds 41, 45.148.10.120 holds 12.
  • What they did: the usual steal — attackers request /.env-style files, our traps hand them real-looking AWS keys, and some keys get used in AWS. This window: 8 mint attempts failed with pacing errors (400s), none with key errors. The one use session ran 14 calls: 4 identity checks passed, 10 real operations were denied.
  • What it means: every credential we hand out is live within hours. AWS denied everything beyond "who are you". The line we watch: any success past identity, or any attempt to create resources, is the escalation.

ACTUATOR-BEDROCK-KIT — a new attacker that steals and uses in the same hour

  • Who: 152.89.244.89, hosted by aurologic GmbH in Germany. It hit only canary-farm-1.
  • What they did: it scanned 59 paths in 151 requests with a bare browser label (Mozilla/5.0): a Vite dev-server file read (/@fs/etc/passwd), a Docker daemon probe (/containers/json), and the full Spring Boot actuator checklist (env, configprops, heapdump, jolokia, mappings, beans). It took 3 /.env credentials, then used one against AWS the same window: 4× sts:GetCallerIdentity passed, then bedrock:InvokeModel ×5, bedrock:ListFoundationModels, SSM DescribeInstanceInformation, EC2 DescribeInstances, and IAM GetRole — all denied.
  • What it means: this is the WEBSIPHON pattern from briefing №55 — steal and immediately test — with AI services as the target. AWS's permission wall held. If it comes back and gets anything past identity, that is the headline.

XMLRPC-BRUTE — the 10,000-login flood, new operator

  • Who: 34.78.138.84, a Google-hosted address in Belgium. The previous operator, 45.94.31.16 (1337 Services, Netherlands), did not show up this window.
  • What they did: 10,000 POSTs to /xmlrpc.php in 4 minutes (about 42 per second), each wrapping the WordPress wp.getUsersBlogs call in a system.multicall envelope, under the fake Chrome/89.0.4389.114 browser label — briefing №67's exact kit. A few side probes came with it: 5 hits on the fake webshell root, plus the usual wlwmanifest and user-enumeration checks.
  • What it means: the flood kit is a product that moves between rented servers. Our fake WordPress answered every request and gave up nothing. Watch for a third node and for the old operator's return.

TECHOFF / PHPSWEEP kit — four scan legs, record width, zero take

  • Who: four addresses from Techoff Srv Limited (Bulgaria): 195.178.110.247, .22, and .159 on canary-farm-1, and .94 on lauterbourg-01-ts. A fifth sibling, .218, ran commands on the frantech-ts login honeypot.
  • What they did: .247 crawled 6,709 paths in 33 minutes under a fake Chrome/123 browser label that misspells its own Safari version (Safari/123.0.0.0): config-file pairs first (/env.js, /config*.js), then about 6,000 HEAD requests for .js.map source-map files. .22 fired 555 requests in 1.06 seconds, including 230 variants of /wp-config.* backup names. .159 walked 376 paths slowly over 11 hours using honest curl/7.81.0. .94 scanned 292 paths on lauterbourg in 3 minutes. Total take: 0 credentials.
  • What it means: wider lists, same result — our decoys answer with 404s and tarpits. Source maps matter only if a server actually serves one; none did here. Any future Techoff credential joins the steal-and-use pool.

CONFIGBUNDLE-KIT — the steady config-census operator

  • Who: 208.84.100.218, on our records since 10-02.
  • What they did: the same config-census shape as always, and it collected 5 canary credentials across 3 sensors (canary-farm-1 2, ai-devbox-1 2, ru-edge-1 1).
  • What it means: five more credentials in attacker hands. No AWS use seen yet; that is the check.

VPN-CONF-HUNT — hunting VPN and cloud config files

  • Who: 85.155.14.15 (netcup-ts) and then 85.155.14.14 (ai-devbox-1), both from SolidCore Hosting in Germany; the .16 and .32 siblings sat out.
  • What they did: .15 tried 356 unique paths in 3 minutes; .14 tried 353 paths across 47 trap families about 7.5 hours later, walking /.aws/credentials, aws_credentials.json, the .aws variants, .boto, .azure/config, and .s3cfg. For the first time, .14 also took a canary credential on ai-devbox-1.
  • What it means: the operator has moved from looking to collecting. Its one credential is unused so far.

REGISTRY-HUNT — the LeakIX-labeled walker pool

  • Who: 164.90.208.56 and 165.227.84.14, both DigitalOcean, both running under the l9scan/2.0.234313… scanner label. The wider pool of 8 DigitalOcean addresses walked our fake admin panels and container registries.
  • What they did: each minted 1 canary on canary-farm-1 after the standard 27-family walk (fake WebLogic, Confluence, cPanel, then docker registry listing).
  • What it means: the credential-minting arm is back after one quiet window. Both credentials sat unused this window. This pool tried Bedrock and SES calls back in №67 and was denied; that remains its known next step.

SI-CENSUS — the biggest stockpiler, working at low volume

  • Who: 102.220.163.241, a VPS provider address in Slovenia.
  • What they did: two 514-request census passes (control-1 and ru-edge-1) plus about 20 light touches on ai-devbox-1 — 1,048 events, down from 5,661 last window. It took 2 credentials (one per census node).
  • What it means: the stockpile stands at 56 credentials per the 6-day Tracebit view, with zero observed AWS use ever. One quiet window proves nothing; two would say the operator changed schedule.

MALWARE-DICT — the malware-URL dictionary loop is back

  • Who: 204.76.203.18, a Pfcloud address in the Netherlands (blocklist: ipsum 2). It hit only control-1.
  • What they did: replayed 579 paths over almost a full day (07:43 11-03 to 06:09 11-04 stored) with no browser label at all — the same endless-loop shape as briefings №13–№14. It took nothing.
  • What it means: the same shared malware-URL list, replayed by the same /24 that ran it before. Its siblings (.10, .7, .50) stayed home.

ENV-FANOUT — watch list

  • Who: 198.145.226.37 (M247, US) made light touches on canary-farm-1 and lauterbourg-01-ts (105 events); its partner 162.216.241.239 did not appear.
  • What it means: the paired .env-fanout kit did not re-run at full size. The promotion triggers stay the same: a third address, any credential, or that fake Chrome/143 label reaching a canary node.

Smaller watchers

  • SS-PROBE, sixth operator. 102.22.219.226 visited all 8 sensors, dropped a fresh marker probe on each canary sensor, then minted 6 credentials (ai-devbox-1 3, control-1 1, ru-edge-1 1, canary-farm-1 1) with the kit's usual python-requests/2.31.0 label. No use yet.
  • 158.140.191.104 (Indonesian hosting, fake Chrome/124): 525 requests on control-1, took 3 credentials at /.env.
  • 185.190.54.150: calls itself Authorized-Audit/1.0, walked 262 paths across 3 sensors, and minted 2 canaries on canary-farm-1 — a research label with collecting behavior, the same pattern as №71's "VantageResearchScanner".
  • GIT-HARVEST, third window running. 35.232.76.162 hit 4 sensors under its honest harvest/1.0 label (80 events). Scheduled, not a one-off; still no credentials.
  • TOKEN-CRAWLER is back. 45.198.224.230/.235/.236 requested long random /c/… token paths on ru-edge-1 (50 events), and .125 touched all 8 sensors (82 events). No credentials.
  • Tarpit loopers — 89.248.172.33 (7 sensors, 394 events), 93.174.93.12 (6 sensors, 374), 91.92.40.12 (8 sensors, 348 events over 2 paths), 45.198.224.125 (8 sensors, 82).
  • 185.177.72.64 (the BUCKLOG census arm) minted 4 credentials (canary-farm-1 2, ru-edge-1 2), 6 over 6 days.
  • Benign, for contrast: Censys-type scanners 71.6.155.70, 94.183.174.99, and 91.224.92.45 covered most sensors at handshake depth and took nothing. On the crypto-honeypot layer, one /.env request came from 70.8.208.88 — that is our own validation client, already identified as benign.

Standing actors (who keeps coming back)

  • SI-CENSUS (102.220.163.241) — present every recent window; volume down this window (1,048 vs 5,661 events); stockpile 56 credentials over 6 days, never used in AWS.
  • Techoff Srv (195.178.110.x, Bulgaria) — ten-plus windows; this cycle it added a four-leg census arm and touched the login honeypot through .218.
  • REGISTRY-HUNT's DigitalOcean pool — present every window on record; the minting arm returned (2 credentials), no use.
  • Pfcloud 204.76.203.18 — its control-1 dictionary loop is back after idle windows.
  • 208.84.100.218 (CONFIGBUNDLE-KIT) — steady since 10-02; 5 credentials this window.
  • 85.155.14.x (VPN-CONF-HUNT) — six-plus windows; first credential this window.
  • 35.232.76.162 (GIT-HARVEST) — third straight window, same shape.
  • 185.177.72.64 (BUCKLOG census) — collecting on two sensors, 6 credentials over 6 days.
  • 137.23.38.53 (SES-QUOTA-PROBE) — light presence this window; after four straight windows of AWS use, it used nothing.
  • 45.198.224.x (TOKEN-CRAWLER) — the /24 keeps rotating addresses; its /c/ token paths returned on ru-edge-1.

Network sweeps (Arkime) — port-22 scans the web traps cannot see

These are SSH banner checks against our 8 public addresses. They request no web page, so the honeypot traps never log them; only the pcap layer (Arkime) sees them. This window: 108,812 inbound sessions, 43 fingerprints with 5+ sessions, 3 flagged as dispersed sweeps, no new fingerprints.

The eight largest fingerprints (id, sessions, source addresses / networks / countries):

  • f555226df1963d1d3c09daf865abdc9a — LIBSSH-MASSSWEEP, banner ssh-2.0-libssh_0.9.6: 1,553 sessions from 183 addresses across 106 networks in 44 countries. Daily address counts, last 7 days: 10-29 657, 10-30 583, 10-31 455, 11-01 610, 11-02 496, 11-03 149, 11-04 66 — contracting.
  • 184781a96d49ee509a431028a8d5022a — OPSSH-UBUNTU-SWEEP, now with banner ssh-2.0-russh_0.45.0 (briefing №71 recorded openssh_9.6p1 ubuntu-3ubuntu13.20 for this same fingerprint): 1,623 sessions from 118 addresses across 78 networks in 37 countries. Daily counts: 11-02 185 addresses, 11-03 118, 11-04 4 — contracting fast. Same fingerprint, new banner: the operator changed tools, or the banner is fake.
  • 0a07365cc01fa9fc82608ba4019af499 — GO-SSH-SWEEP, banner ssh-2.0-go: 24,551 sessions from 60 addresses across 29 networks in 17 countries — back over the dispersed-sweep line (50+ addresses), though 12,657 fewer sessions than last window. Its busiest addresses (77.239.124.x, 109.160.32.x) are the same blocks that ran the login-honeypot hardware survey in past windows.
  • 16443846184eafde36765c9bab2f4397 — GO-SCATTER-SWEEP: 14,284 sessions from 37 addresses across 20 networks in 15 countries.
  • 084386fa7ae5039bcf6f07298a05a227 — unnamed: 39 sessions, 32 addresses, 7 networks, 9 countries.
  • 03a80b21afa810682a776a7d42e5e6fb — LIBSSH-011-SWEEP, banner ssh-2.0-libssh_0.11.1: 176 sessions, 28 addresses, 16 networks, 4 countries.
  • dd9bcf093c355da7000132131cb36fd0 — unnamed: 30 sessions, 28 addresses, 1 network, 1 country.
  • e54ef3ec27fe1fea7ab64d3fa05359fd — unnamed: 40 sessions, 20 addresses, 7 networks, 5 countries.

None of these tried to log in. What it means: the sweeps map who runs SSH where; they take nothing by themselves, but any login attempt from one of these fingerprints would change its class. Control-1 again absorbed the fleet's heaviest single load: 57,854 inbound sessions, 31,147 of them from CTL-MASS-SSH (4e066189c3bb…) — its fourth window in a row above 27,000 sessions.

Canaries (minted and used) — how the trap credentials moved

The window in one line: 67 credentials minted to 41 attacker addresses; 1 credential used in AWS; 66 sitting in attacker hands.

The digest's own mint table counted 83 issued rows (canary-farm-1 32 from 26 addresses, ai-devbox-1 28 from 23, control-1 12 from 10, ru-edge-1 11 from 10); the difference from 67 is how the two systems trim the same 24 hours. Mint failures: 8, all pacing errors (400s) — canary-farm-1 3, ai-devbox-1 3, control-1 1, ru-edge-1 1. No key errors.

The one use: 152.89.244.89 used a credential it had minted itself on canary-farm-1 — 14 AWS calls, 4 identity checks passed, 10 operations denied (InvokeModel ×5, ListFoundationModels, SSM DescribeInstanceInformation, EC2 DescribeInstances, IAM GetRole, with ListBuckets also in the operation set).

The bigger collectors this window (address, sensor, credentials taken, AWS use): 102.22.219.226 ai-devbox-1 3 (0 used); 152.89.244.89 canary-farm-1 3 (1 used — the Bedrock session); 158.140.191.104 control-1 3 (0); 167.99.210.137 canary-farm-1 2 (0, 3 over 6 days); 185.177.72.64 canary-farm-1 2 and ru-edge-1 2 (0, 6 over 6 days); 207.154.212.47 ai-devbox-1 2 (0); 208.84.100.218 ai-devbox-1 2, canary-farm-1 2, ru-edge-1 1 (0, 5 over 6 days); 95.174.64.238 ai-devbox-1 2 (0). The rest took 1 each.

Long-term stockpiles with no observed AWS use (the Tracebit 6-day view): 102.220.163.241 holds 56; 34.95.21.228 holds 41; 45.148.10.120 holds 12; 150.241.66.127 holds 10; 46.148.227.131 holds 7; 45.138.12.16 holds 6; 74.0.42.13 holds 6; 185.177.72.64 holds 6; 102.22.219.226 holds 6. Every one of these is a live credential until it expires. The full per-collector table is in the technical version.

How the fleet behaved (Fleet Observations) — volumes, defenses, the fresh node

  • Traffic moves had clear causes. lauterbourg-01-ts rose 324% (13,059 events) because of the 10,000-POST WordPress flood. frantech-ts fell 97% (517 events) because MEGA-DICTIONARY did not replay. ai-devbox-1 fell 56% (2,491) and ru-edge-1 fell 67% (1,169) because last window's heavy scanners idled. canary-farm-1 fell 23% (10,918) even though Techoff added about 8,200 events — the other heavies were gone. control-1 rose 40% (3,715) on the Pfcloud dictionary loop (1,837), the Indonesian census (525), and the walkers. We checked sync coverage: every sensor's newest event landed between 10:51 and 12:22 UTC on 11-04, so these drops are real, not missing logs. One quirk to remember: events near the boundary show up in two daily digests.
  • Canary economics. 83 mint rows, 8 pacing failures, no key errors. Through the alert side: 67 credentials to 41 addresses, 1 used in AWS, 66 unused.
  • Attribution checks are clean. 2,563 requests carried an X-Forwarded-For header; 0 forged multi-entry chains; 7 headers that agreed with the connection; 0 forgeries that claimed a different source than the one that connected — the fourth quiet window in a row. Web traffic ran plain-HTTP-first on every node (canary-farm-1: 10,053 HTTP vs 865 HTTPS). Top fake hostnames: cloud.wafflehouseindex.us 11,631 requests (inflated by the flood), sso.rightabouteverything.show 1,168, inference.fapthropic.com 867. The retired kiteworks hostname drew no notable traffic this window (last window: 706).
  • The fresh-IP baseline node (control-1) is 52 days old. Its full day ran 3,715 events from 127 addresses — inside the 7-day band (1,179–5,138 events, 104–155 addresses) and 40% above the weekly event average, driven by the dictionary loop and the two census operators. The network layer still aims the fleet's biggest SSH load at it (CTL-MASS-SSH, 31,147 sessions).
  • First-seen lists need care. Every new path and browser label in the digest shares one sync timestamp, so the list is an inventory, not a timeline. We matched them by hand: the /wp-config.* backup names and plugin exploit paths came from Techoff's .22 burst, and the long random /c/… paths on ru-edge-1 came from TOKEN-CRAWLER.
  • Crypto honeypot (ch-sponge-01-ts), platform view: 2,817 records from 957 sessions and 183 addresses since 11-03 07:34 UTC. Busiest services: Telnet 907 records, HTTP 719, a Monero wallet RPC 457. Busiest sources: 20.164.200.48 (368 records), 193.32.249.162 (326), 169.150.196.5 (226). The alerts include 21 CVE attempts, 5 key-theft attempts, and 8 transfer attempts; 3 requests aimed at the /.env bait (one from 70.8.208.88 — our own validation client, benign — one from loopback, one from 13.140.235.56); 1 Docker dropper indicator from 220.181.1.163. The packet-level view stays in Arkime.
  • No fleet changes were made this cycle.

SSH/telnet honeypot (frantech-ts — one host, not fleet-wide)

One host, so never treat these as fleet numbers. This window: 317 addresses sent login attempts → 204 got a shell (64%) → 151 ran a command (74% of those who got a shell). In raw events: 8,188 login attempts → 3,363 accepted logins → 10,050 commands. The telnet side (IoT botnets) saw 467 attempts.

No operator ran a command we had never seen before (0 of 4,494 distinct commands) — the third quiet window in a row. No new username/password pair appeared either (0 of 3,656 offered). What did move: the most-used password pair this window is now rootssssss23424123123/rootssssss23424123123 (175 tries), and the old gs5662d34 family showed up with longer tails (root/root3245gs5662d34111111111 149 tries, 345gs5662d34 111, root/3245gs5662d34 87). The everyday commodity pairs followed: root/123456 87, pi/raspberry 69, user/wasd 62.

The repeated commands stay the same: a hardware-check loop (uname -s -v -n -r -m and its awk helper, 1,927 runs each from 3 addresses — the same 109.160.32.x block that runs the port-22 GO-SSH-SWEEP), an SSH key-planting routine (chattr -ia .ssh, then writing an SSH key, 297 and 241 runs from 114 and 100 addresses), and a GPU-discovery pass from 195.178.110.218 (157 runs each of nvidia-smi and lspci checks) — that last one is the same Techoff organization that ran this window's web census, working the login honeypot too.

Staging servers (the C2 view, same one host)

The honeypot saw one new download server this window: http://5.175.192.232/bot_mips, first used 2026-11-04 at 00:22 UTC. It served a 2.4 MB file (sha256 afdbab3c1c43aceaeb9117c725e8c6f5db89eafbda2ee18f958d02d2bde30e95) twice to one address. We read the file read-only on the honeypot: it is a 32-bit MIPS program, statically linked, built with Go 1.22.5, and stripped of names. It carries no readable web addresses we could extract, so we cannot name the family — the file name says IoT bot, the Go toolchain says it is not one of the usual C-language bot families. We will not guess.

Two older download addresses stayed active: http://160.119.66.206/bins/kla.sh (live since 09-18, 528 command runs this window, still serves nothing) and https://217.60.102.5/sh (20 tries from 10 addresses, serves nothing — a known staging path from the LIBREDTAIL kit's network block).

Open questions

  1. Will 152.89.244.89 try AWS again? Everything past identity was denied. A retry, any success past identity, or any attempt to create resources is the escalation line. Its other 2 stolen credentials are still live until they expire.
  2. Is the 10,000-login flood kit on a schedule? A third node under the same shape (or the return of 45.94.31.16) would tell us the kit rotates on its own.
  3. What was Techoff's .js.map crawl looking for? Source-map files reveal how an application is built when a server actually serves them. All 6,000 requests here got 404s. A second node, any 200, or any credential from this arm would tell us more.
  4. Will SS-PROBE's sixth operator (102.22.219.226) use its 6 fresh credentials? Any alert naming it extends the ledger from stealing to using.
  5. Which is it for OPSSH-UBUNTU-SWEEP: new tool or fake banner? Same fingerprint, new banner (russh_0.45.0 instead of the Ubuntu OpenSSH string). A third banner would support spoofing; a stable client supports a tool change. Any login attempt reclassifies the sweep as an attack.
  6. Is MEGA-DICTIONARY paused or between runs? It idled this window. A fourth host replaying the 14,864-path list would prove the list is circulating; a second quiet window would raise the pause question.

Plain language version of: flux-fleet-intel-briefing-2026-11-04.md