48 lines
2.8 KiB
Markdown
48 lines
2.8 KiB
Markdown
 
|
# Interactive Terminal Spawned via Python (Elastic detection rule)
|
||
|
|
|
||
|
|
## Metadata
|
||
|
|
|
||
|
|
| Field | Value |
|
||
|
|
|---|---|
|
||
|
|
| Institute | Molodetz Institute — Research & Retrieval Division |
|
||
|
|
| Subject | shell-multiplexer-auto-attach |
|
||
|
|
| Document type | Source Dossier |
|
||
|
|
| Tier | 1 |
|
||
|
|
| Source title | Interactive Terminal Spawned via Python |
|
||
|
|
| Source URL | https://detection.fyi/elastic/detection-rules/linux/execution_python_tty_shell/ |
|
||
|
|
| Source publisher / author | Elastic (detection-rules), mirrored by detection.fyi |
|
||
|
|
| Source type | vendor docs |
|
||
|
|
| Source date (published) | Unknown — not stated |
|
||
|
|
| Date researched | 2026-10-09 |
|
||
|
|
| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
|
||
|
|
| Research method | web search synthesis |
|
||
|
|
| Confidence | High |
|
||
|
|
| Status | Active |
|
||
|
|
|
||
|
|
## Summary
|
||
|
|
|
||
|
|
A security detection rule (also mirrored at elastic.co's own docs) that fires when a Python process spawns an interactive pty-backed shell — a pattern commonly associated with reverse shells, but one the rule's own documentation explicitly acknowledges is also produced by legitimate administrative scripts and automation tools. The prescribed remediation for false positives is to identify and allowlist the specific known-good tools, not to weaken the detection signal itself.
|
||
|
|
|
||
|
|
## Key findings
|
||
|
|
|
||
|
|
- A security vendor, writing a detection rule specifically meant to catch malicious activity, independently concludes that "spawns an interactive pty" is not by itself a reliable signal of anything in particular (malicious or benign) — it needs context (which process, with what parent, doing what) to be meaningful.
|
||
|
|
- The recommended fix for false positives is allowlisting by known tool identity, not by relaxing the pty-interactivity check — i.e., the right axis to add is "who/what is doing this," not "make the interactivity test looser."
|
||
|
|
|
||
|
|
## Pros / strengths
|
||
|
|
|
||
|
|
- Comes from the security-detection domain, which has spent years dealing with exactly this ambiguity at scale (distinguishing legitimate automation from malicious activity using the same low-level signals) — directly transferable experience for this subject's human-vs-automation problem.
|
||
|
|
|
||
|
|
## Cons / limitations / caveats
|
||
|
|
|
||
|
|
- Framed around detecting malicious reverse shells, not around a shell startup hook's design; the finding (allowlist by identity, not by loosening the raw signal) transfers, but the specific rule logic itself does not.
|
||
|
|
|
||
|
|
## Relevance to tai
|
||
|
|
|
||
|
|
Validates the proposal's approach of combining `$-`/`$TMUX`/`$SSH_TTY` with an explicit allowlist/denylist of known parent-process names or environment markers (e.g. skip auto-attach when the parent is `claude`, `code`, a CI runner, etc.) rather than trying to find one perfect universal signal — exactly the security industry's own conclusion on the identical underlying ambiguity.
|
||
|
|
|
||
|
|
## Changelog
|
||
|
|
|
||
|
|
| Date | Change |
|
||
|
|
|---|---|
|
||
|
|
| 2026-10-09 | Initial dossier created. |
|