TTY Logs and the Data it Captures

1. Executive summary

A SANS Internet Storm Center diary describes a honeypot-logging experiment in which TTY session logs from the DShield Cowrie sensor are parsed daily and shipped to the DShield SIEM for correlation. A single transaction ID (f904275333aeac48d7df6cf53fe5fb9212c7d132a7d37253d2ab9321ba2690d8) captured five similar crontab commands executed by more than 3,130 distinct source IPs over a 90 day period, and the diary publishes a top-10 source IP list with ASNs. No CVE, no named threat actor, and no victim organisation are identified; this is a research and telemetry note, not a report of a compromise at a specific firm. The relevance to EMEA financial services is indirect: the crontab commands and source IPs are commodity SSH-brute-force post-login behaviour that will appear in any internet-exposed SSH estate, and the diary's method (hashing TTY command output to cluster actor behaviour) is a detection technique clients can copy. No verified reference data was resolved for this item, so no CVSS score, severity, or CISA KEV state is asserted.

2. Regulatory framing

No specific DORA/NIS2 article is directly engaged by this item. The diary reports honeypot telemetry and a correlation method; it does not describe an incident at a regulated entity, a supply chain event, or a reportable operational disruption. The source IPs and crontab commands are commodity scanning and post-login activity, which is true of virtually any internet-facing SSH service and does not by itself trigger a reporting obligation. Clients who observe the same crontab commands succeeding against their own estate should assess DORA Art. 18 (classification of ICT-related incidents and cyber threats) and DORA Art. 19 (reporting of major ICT-related incidents to competent authorities) against their own incident facts, not against this diary.

3. Technical analysis & attack chain

The item is a research note, not an incident report. There is no confirmed attack chain against a named victim. What the diary documents is a logging and correlation pipeline and the commodity behaviour it captured.

The pipeline, as described:

1. Actors or bots log in to the DShield Cowrie sensor.
2. Cowrie records the interactive session as a TTY log.
3. A script (daily_tty.sh) parses those TTY logs and sends them once per day to the DShield SIEM.
4. The SIEM correlates the parsed command data against other DShield telemetry.

The correlation query is Elastic ES|QL against the cowrie* index pattern. It filters on a specific transaction.id, requires event.hash to be non-null, keeps transaction.id and event.hash, aggregates a count of event.hash grouped by hash and transaction ID, and sorts descending by count. The diary states this transaction ID captured five similar crontab commands, translated from their hash equivalents, executed by more than 3,130 different source IPs over a 90 day period. The five crontab commands themselves are not reproduced in the source, only their hashes and the aggregate count. That is a material gap: an analyst cannot reconstruct the exact command lines from this diary alone.

The diary also publishes a top-10 source IP list with ASNs, presented as "Top 10 Indicators":

What this tells a defender: the behaviour is SSH login followed by crontab manipulation, which is the standard persistence step for commodity botnets that survive reboot and re-establish a downloader or miner. The diary does not name the payload, the download URL, the miner family, or the botnet. It does not state the credentials used, the SSH versions targeted, or whether the logins were brute-force, credential-stuffing, or default-credential. None of that is in the source, so none of it is asserted here.

Confidence caveats. This is a single source (SANS ISC, author Guy Bruneau, IPSS Inc.). The 3,130-actor figure and the five-crontab-command cluster rest entirely on that one diary and its underlying DShield dataset, which is not published in the item. The top-10 IP list is a snapshot of honeypot source addresses, not a confirmed list of attacker infrastructure against any client. Treat the IPs as low-confidence pivots for hunting, not as a blocklist.

4. Mitigation & containment

The diary does not describe a compromise at a client, so these are hardening and hunting steps for internet-exposed SSH estates, prioritised by the behaviour the diary actually captured (successful login followed by crontab execution).

P1 (within 24h)

• Hunt for the behaviour, not the IPs. Search authentication and process telemetry for successful SSH logins followed within the same session by crontab execution. On Linux, auditd execve records for /usr/bin/crontab and /bin/crontab, and shell history or EDR process trees showing crontab - or crontab -e from an interactive SSH session, are the highest-value pivots.
• Review all crontab entries across internet-facing hosts for entries created outside your change process. Check /var/spool/cron/crontabs/<user>, /var/spool/cron/<user>, /etc/crontab, /etc/cron.d/, and /etc/cron.{hourly,daily,weekly,monthly}/. The diary does not give the command content, so triage on provenance (who created it, when, from which session) rather than on a known-bad string.
• Disable SSH password authentication on any internet-exposed host that still permits it, and require key-based auth. This removes the login step the diary's actors depend on.

P2 (within 72h)

• If you run Cowrie or another SSH honeypot, adopt the diary's method: parse TTY logs daily, hash the command output, and cluster by hash to find commands executed by many distinct source IPs. The daily_tty.sh script and the DShield SIEM are published at the GitHub links in §7. The ES|QL query in §3 is the correlation step and can be adapted to any Elastic deployment holding Cowrie logs.
• Rate-limit and geo-restrict SSH where business need allows. The source IPs in §5 span multiple ASNs and regions; there is no single ASN to block, so rate-limiting and fail2ban-style lockouts are more useful than static blocks.
• Confirm outbound egress filtering on internet-facing hosts. Crontab persistence in commodity botnets typically exists to re-fetch a payload; blocking unexpected outbound connections from these hosts limits the value of the persistence.

P3 (within 7 days)

• Add the crontab-execution-after-SSH-login pattern to detection content (see §6) and tune it against your own baseline before enabling alerting.
• Review whether your SSH estate has any hosts where a successful brute-force login would go unnoticed. The diary's core finding is that 3,130 distinct IPs ran the same five commands, which means the behaviour is common enough that it will not stand out without a specific rule.

5. Indicators of compromise

The only atomic indicators in the source are source IP addresses from a honeypot, plus one transaction ID and one event-hash correlation key. There are no file hashes, domains, or URLs. The IPs are single-sourced honeypot source addresses; verify before enforcement.

ipv4  102.88.137[.]80
ipv4  42.96.20[.]16
ipv4  182.253.221[.]210
ipv4  46.188.119[.]26
ipv4  159.223.97[.]218
ipv4  185.158.22[.]150
ipv4  193.233.48[.]169
ipv4  209.99.190[.]200
ipv4  45.64.74[.]51
ipv4  202.152.148[.]27

Behavioural indicators. The diary describes behaviour but publishes no command strings, so the following are the observable patterns implied by the source, not atomic indicators.

6. Detection

The source gives no file hashes, no command strings, no filenames, and no registry keys. The only distinctive artefacts are the transaction ID and the correlation query, neither of which is a threat artefact suitable for a YARA rule. A YARA rule built on the IP list or the transaction ID would detect reporting about the activity, not the activity, so none is emitted.

For Sigma, the behaviour the diary describes (SSH login followed by crontab execution) is detectable from process telemetry. The rule below keys on that pattern. It uses only the command names present in the source (crontab) and standard Linux process telemetry fields; it does not embed any invented string.

title: Crontab Execution Following SSH Login
id: 8f3c1a2e-5b7d-4c9a-9e21-0d6f4a7b2c11
status: experimental
description: Detects crontab execution in a session that follows an SSH login, matching the post-login persistence behaviour described in the SANS ISC TTY log diary.
author: Adverse Trace
date: 2026-10-05
references:

  - https://isc.sans.edu/diary/rss/33396
logsource:
  product: linux
  category: process_creation
detection:
  selection_crontab:
    Image|endswith:

      - '/crontab'
    CommandLine|contains:

      - 'crontab'
  condition: selection_crontab
falsepositives:

  - Legitimate administrative crontab changes
  - Configuration management tooling that manages cron entries
level: low

This rule is deliberately broad. It will fire on legitimate administration. Correlate it with an SSH login event from the same session and with the source IPs in §5 before escalating. The diary does not provide enough detail to narrow it further.

7. Sources

• Guy Bruneau, IPSS Inc., "TTY Logs and the Data it Captures", SANS Internet Storm Center, 2026-10-05. https://isc.sans.edu/diary/rss/33396
• DShield Sensor daily TTY script (daily_tty.sh), referenced in the diary. https://github.com/bruneaug/DShield-Sensor/blob/main/sensor_scripts/daily_tty.sh
• DShield SIEM, referenced in the diary. https://github.com/bruneaug/DShield-SIEM
• Elastic ES|QL reference, referenced in the diary. https://www.elastic.co/docs/reference/query-languages/esql

8. Adverse Trace position

Adverse Trace assesses this as a low-severity research note with no direct client impact and no verified reference data to anchor a CVSS score or exploitation state. The value to clients is the detection method and the reminder that SSH login followed by crontab execution remains common commodity behaviour: 3,130 distinct source IPs ran the same five commands over 90 days in one honeypot's telemetry. The source IP list is single-sourced honeypot data and we do not recommend blocking on it; use it for hunting only. We will monitor DShield and SANS ISC for a follow-up that publishes the actual crontab command content, since that is the missing piece that would let clients write a precise detection rule, and we will re-issue this advisory if the command strings or any associated payload are published. Clients who see the crontab-after-SSH-login pattern succeeding in their own estate should treat it as a potential incident and assess DORA Art. 18 and Art. 19 against their own facts.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.