2026  July(5) August(40) September(4) October(0) November(0) December(0) | STATISTICS (0) | H  ARTICLES  CONFERENCE  MALWARE TRAFFICS

YARA-X's 1.20.0  Wireshark 4.6.8 Released

Linux Detection Engineering - Local Privilege Escalation

14.9.2026  ELASTIC  OS

Seven of the thirteen Linux privilege escalation CVEs we tracked in 2026 turned out to be the same copy-on-write bug pointed at different kernel interfaces. We ran the public proof-of-concept for eleven exploits and two misconfigurations, and noted which rules fired.

Local privilege escalation (LPE) is the step that turns a foothold into full control of a host. An attacker who lands as an unprivileged user rarely stops there. They want root, and Linux keeps offering new ways to get it.

In this edition of our "Linux Detection Engineering" series, we’ll cover:

The default flow that a Linux LPE produces on the host and the general rules that detect it.

The recurring LPE patterns behind the most recent LPEs and how each works, along with how each looks through the lens of Elastic Defend.

The Elastic detection and endpoint rules that fire on each.

Over the past year, the pace of publicly disclosed Linux LPEs has picked up sharply, and the shape of those disclosures has changed with it.

For most of the last decade, escalations arrived steadily but from all over the map, including from trusted helpers like sudo, pkexec, and polkit; kernel bugs scattered across Executable and Linkable Format (ELF) loading, ptrace, eBPF, and packet sockets; and user namespaces widening what an ordinary account could reach. That variety kept the workload manageable. Each bug had its own subsystem and write-up, so reading each advisory as it landed and adding a rule for that technique worked.

Then came 2026.

Seven of the 13 disclosures that we track here share one bug class: a copy-on-write or zero-copy path that writes into data that it was supposed to copy first. Copy Fail opened in April 2026, and DirtyFrag, Fragnesia, DirtyDecrypt, and DirtyClone pushed the identical idea through ESP, RxRPC, and the socket-buffer fragment helpers within weeks. pedit COW moved it into traffic control. RefluXFS took it back to the filesystem in July 2026. Neither figure is a census, so read them as a picture of how the work changed rather than a count of every bug.

Qualys attributes RefluXFS to a research effort with Anthropic, pointing Claude Mythos Preview at the kernel's memory-management and filesystem code to hunt for a DirtyCOW-style race and then reproducing and verifying the result before disclosure. The author of OVSwrap credits a comparable large language model-assisted (LLM-assisted) workflow. Both teams kept humans on validation and disclosure, and LLMs are unlikely to be the only factor here. What the two write-ups show is the loop itself: hand a model a known bug class, ask for a new instance, repeat. When one idea can be aimed at a dozen kernel interfaces in a quarter, a detection rule written per Common Vulnerabilities and Exposures (CVE) keeps arriving late.

The good news is that most LPEs, however novel the trigger, share a single detectable flow, and beyond it, they fall into a small number of bug classes. So we detect in two layers: a general layer keyed on the flow every escalation produces (an unprivileged process becoming root), and a per-technique layer that adds signal specific to a bug class.

Setting up Elastic Defend and Auditd to detect Linux privilege escalation
To follow along and generate the telemetry shown here, enable the prebuilt rules and reproduce the techniques in a lab:

In Kibana, navigate to Security -> Rules -> Detection rules (SIEM), and install the Elastic prebuilt rules. Enable the Linux privilege escalation rules (by filtering on tags OS: Linux and Tactic: Privilege Escalation).

Deploy Elastic Defend on a Linux test host for endpoint (behavioral) coverage.

For syscall-level visibility, enable the Auditd Manager integration. The page-cache class, in particular, relies on socket, splice, and bind auditing, as well as execve. The Copy Fail and DirtyFrag research lists the exact auditd rules to add.

Reproduce each technique safely in a disposable virtual machine (VM) using the relevant public proof of concept (PoC). Treat all exploit code as lab-only, and never run it against systems that you don’t own.

All of the rules mentioned in the blog are available as a detection and/or endpoint rule. Detection rules live in Elastic’s detection-rules repository, while endpoint rules live in Elastic’s protections-artifacts repository.

The limitations of this Linux privilege escalation detection framework
This post is built around the public PoC for each vulnerability. We’re aware that a PoC can be modified: swap the targeted setuid binary, change paths, or reshape the exploit to sidestep a specific match. That’s exactly why the detection is layered and outcome-oriented rather than tied to any one implementation. The goal is a general LPE detection framework that holds up across reimplementations and covers the shared flow that every escalation produces.

We aren’t claiming to detect 100% of Linux LPEs, and certainly not an LPE custom-built to evade these detections. What we aim for is broad, durable coverage of the way that escalations actually behave on a host, with LPE technique-specific rules covering the foundations and bug class-specific rules to catch those that were missed.

How Linux privilege escalation detection works: The flow that every exploit produces
Almost every local privilege escalation, whatever the underlying bug, produces the same skeleton of activity on the host:

An unprivileged user (uid != 0) runs something, usually a freshly dropped or compiled binary, a script, or a shell one-liner, from a location that they can write to (for example, /tmp, /dev/shm, /var/tmp, /home, or /run/user/).

Moments later, a process in that lineage is running as root: a uid_change to 0, an effective uid or guid of 0, or an interactive root shell.

In certain PoCs, the exploit then confirms success by running whoami, id, or logname.

That "exec from a writable path and become root" skeleton is the backbone of our general detection. Because these rules key on the outcome and its immediate context rather than on any exploit-specific artifact, they cover a broad class of LPEs, including ones that we’ve never seen. They’re also what catch the page-cache family and the no-userland-tell kernel bugs, where there’s nothing implementation-specific to match.

Detecting SUID and SGID helper abuse
Setuid-root binaries and helpers are the single most common final step in a Linux LPE, because they’re the sanctioned way for an unprivileged user to run something as root, so any slip in how one of them behaves hands over that privilege. What ties the subcases together is the privilege shape: a process running with effective uid 0 while the real user (and usually the parent) is not, launched with minimal arguments from an interpreter, a shell one-liner, or a writable path. We split the coverage by how the abused binary is chosen, from the handful of helpers that appear in almost every write-up, out to the long tail and the proxying tricks that a name-based rule misses. This category maps to the Abuse Elevation Control Mechanism: Setuid and Setgid (T1548.001) technique on the MITRE ATT&CK matrix.

Detecting abuse of su, sudo, pkexec, and passwd
A short list of setuid helpers (su, sudo, pkexec, passwd) accounts for the overwhelming majority of real-world SUID abuse, whether as the finishing move of a memory-corruption exploit or a plain misconfiguration. A dedicated, tightly scoped rule for these keeps false positives near zero while covering the common case, so it’s the first thing to reach for.

Let’s begin by covering the different building blocks relevant to building a strong yet general SUID LPE detector, one by one. The following logic looks for instances where either the user or group ID is 0, while the real user/group ID is not. This is a default and benign SUID behavior and would trigger on typical sudo usage by a user.

(
(process.user.id == 0 and process.real_user.id != 0) or
(process.group.id == 0 and process.real_group.id != 0)
)

This logic is followed by the execution of a commonly abused SUID helper with a low process argument count. This already cuts down the false positive rate drastically. For example, in a benign use case, the sudo command is generally used with additional arguments, making a sudo invocation with an argument count of 1 rare. However, just relying on these two building blocks isn’t strong enough to be a detection on its own, as this activity still happens too frequently in benign scenarios.

(
(process.name == "su" and process.args_count <= 2) or
(process.name == "sudo" and process.args_count == 1) or
(process.name == "pkexec" and process.args_count == 1) or
(process.name == "passwd" and process.args_count <= 2)
)

The euid-0 / non-root-real-user shape is paired with an interpreter, writable-path, or shell one-liner parent, which is what separates exploitation from a user legitimately typing sudo.

(
process.parent.name like (
".*", "python*", "perl*", "ruby*", "lua*", "php*", "node",
"deno", "bun", "java"
) or
process.parent.executable like (
"./*", "/tmp/*", "/var/tmp/*", "/dev/shm/*", "/run/user/*",
"/var/run/user/*", "/home/*/*"
) or
(
process.parent.name in (
"bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "mksh"
) and
process.parent.args in ("-c", "-cl", "-lc", "--command", "-ic", "-ci") and
process.parent.args_count <= 4
)
)

And it’s followed by a bunch of known legitimate exclusion activity. Combining these three building blocks makes for a strong general SUID/SGID helper LPE detection. This logic maps to Suspicious SUID/SGID Utility Execution.

Detecting uncommon SUID binaries without a name list
Not every abused SUID binary is on that short list. This variant drops the hard-coded names entirely and keys on the privilege shape plus a self-referential command line (the process was invoked as itself), which is what a freshly abused, less common setuid binary looks like on the wire. We still check beforehand to see whether we’re dealing with a SUID binary:

(
(process.user.id == 0 and process.real_user.id != 0) or
(process.group.id == 0 and process.real_group.id != 0)
)

But this is quickly followed by the main logic differentiator between these different rules, which is displayed below:

(
stringcontains(process.executable, process.command_line) or
stringcontains(process.name, process.command_line)
)

Instead of relying on allowlisting a list of known SUID binaries, we use a clever stringcontains Event Query Language (EQL) trick. By using the stringcontains function, we can compare the process.executable to the process.command_line value (or process.name to process.command_line), effectively matching on instances where an unknown SUID binary (which we established through the user.id versus real_user.id comparison) is executed directly. The gap it fills is the long tail: because there’s no name list, there’s no blind spot for whichever setuid binary a given system happens to ship, at the cost of a broader exclusion list for legitimate helpers.

We follow this rule with an exclusion of known SUID helpers, to minimize coverage overlap with the previous (and other) rules. This maps to Potential Privilege Escalation via a SUID/SGID Binary.

Detecting SUID helper proxy execution via process arguments
Some abuse doesn’t run the helper as the process itself; it hands the helper as an argument to another privileged binary, proxying the execution so a name-based rule sees the wrong thing. The tell is a process whose command line starts with its own executable, a single-argument parent, and a known setuid helper path sitting in the arguments.

process.args in (
"/bin/su", "/usr/bin/su",
"/bin/umount", "/usr/bin/umount",
"/bin/chfn", "/usr/bin/chfn",
"/bin/chsh", "/usr/bin/chsh",
"/bin/gpasswd", "/usr/bin/gpasswd",
"/bin/newgrp", "/usr/bin/newgrp",
"/usr/bin/newuidmap", "/usr/bin/newgidmap",
"/usr/lib/dbus-1.0/dbus-daemon-launch-helper",
"/usr/libexec/dbus-daemon-launch-helper",
"/usr/lib/openssh/ssh-keysign", "/usr/libexec/openssh/ssh-keysign",
"/usr/bin/pkexec", "/usr/libexec/pkexec", "/usr/lib/polkit-1/pkexec",
"/usr/lib/snapd/snap-confine"
) and
process.args_count <= 2

The proxy execution rule differs from the two rules above by looking at the helper in process.args rather than process.name, so it catches the proxying pattern (binfmt_misc style and similar) that name-based matching would miss entirely. Although not exhaustive, the argument list does target the most commonly available SUID helpers on a default Linux system. This maps to Potential Privilege Escalation via SUID/SGID Proxy Execution.

Further SUID and SGID privilege escalation rules
We didn’t get into every SUID-based LPE rule that we created to cover this attack vector. We encourage anyone interested in digging deeper to take a look at our other public rules related to SUID/SGID LPE, which can be found here:

• Suspicious SUID Binary Execution (and its Auditd variation)

• Privilege Escalation via SUID/SGID

• Potential Privilege Escalation via SUID/SGID

• Suspicious SUID/SGID Utility Execution

• Potential Privilege Escalation via SUID/SGID Proxy Execution (and its Elastic Defend counterpart)

• Potential Privilege Escalation via a Known SUID/SGID Binary

• Potential Privilege Escalation via a SUID/SGID Binary

Self-elevation: Exec from a writable path and then a UID change to root
Many kernel and logic exploits never touch a helper; the exploit process, or something in its lineage, simply becomes root. The observable is always the same pair: a non-root process execs from a writable path (/tmp, /dev/shm, /var/tmp, /home/*, /run/user/*), and shortly after, a process in that lineage emits a uid_change to 0. The subcases differ only in how tightly we can tie the exec to the elevation and in whether the exploit politely confirms its own success.

Detecting exec and then elevating by correlating on the parent process
The most general form correlates the two events by their shared parent: a non-root, interactive exec from a writable path, followed by a uid_change to 0 under the same parent, within a short window.

sequence by process.parent.entity_id with maxspan=15s
[process where event.type == "start" and event.action == "exec" and
user.id != 0 and process.parent.user.id != 0 and
process.parent.group.id != 0 and
(
process.executable like (
".*", "/tmp/*", "/dev/shm/*", "/var/tmp/*", "/run/user/*",
"/var/run/user/*", "/home/*/*"
) or
process.parent.executable like (
".*", "/tmp/*", "/dev/shm/*", "/var/tmp/*", "/run/user/*",
"/var/run/user/*", "/home/*/*"
)
)]
[process where event.type == "change" and event.action == "uid_change" and
user.id == 0 and process.parent.user.id != 0 and
process.parent.group.id != 0]

It needs no recon command and no known binary, just the exec-then-elevate pair from a world-writable location, so it fires on self-elevating exploits that give nothing else away. Given that this activity is also known to fire on false positives (edge cases where benign precompiled binaries in /tmp or /home directories elevate), this rule requires slightly more tuning to fit in well with your environment. For static server environments, the rule should generally be plug and play. This maps to Potential Privilege Escalation via a Parent Process Sequence.

Using descendant-of to catch root transitions several processes deep
The root transition doesn’t always land in the immediate child. When a web server or interpreter running as a service account spawns a chain that ends in an interactive root process several hops down, a direct parent/child correlation breaks. To combat this, we added another layer, using the descendant of functionality.

In this query, we target interactive executions where the user.id is 0, while the parent user is a nonsystem user (uid >= 1000).

process where event.type == "start" and event.action == "exec" and
process.interactive == true and user.id == 0 and (
process.parent.user.id >= 1000 or
process.parent.user.name in (
"apache", "www-data", "httpd", "nginx", "lighttpd", "tomcat",
"tomcat8", "tomcat9", "ftp", "ftpuser", "ftpd"
)
)

The interactive-root match is then followed by descendant of logic, where the descendant is an executable launched from a world-/user-writable location.

descendant of [
process where event.type == "start" and event.action == "exec" and
user.id != 0 and
process.executable like (
".*", "/tmp/*", "/dev/shm/*", "/var/tmp/*", "/home/*/*",
"/run/user/*", "/var/run/user/*"
)
]

sing descendant of instead of a fixed parent link accommodates any depth of intermediate processes, and folding in service accounts (uid >= 1000, or www-data, nginx, tomcat) covers the web-shell-to-root path that the sequence rules can miss. This maps to Potential Local Privilege Escalation via a Suspicious Descendant Process.

Detecting the exec, elevate, and confirm sequence
When the exploit verifies its own success (the near-universal habit of running id, whoami, or logname right after getting root), we can require all three stages: the writable-path exec, the uid_change to 0, and then the privilege check as root.

sequence with maxspan=10s
[process where event.type == "start" and event.action == "exec" and
user.id != 0 and process.executable like (
".*", "/tmp/*", "/dev/shm/*", "/var/tmp/*", "/home/*/*",
"/run/user/*", "/var/run/user/*"
)] by process.entity_id
[process where event.type == "change" and event.action == "uid_change" and
user.id == 0] by process.entity_id
[process where event.type == "start" and event.action == "exec" and
process.name in ("whoami", "id", "logname") and
user.id == 0] by process.parent.entity_id

The confirm stage is what makes this the lowest-false-positive, highest-true-positive signal of the group for public PoCs, which frequently check their work, so it’s the rule to lead an investigation with. This maps to General Privilege Escalation Sequence Detected.

Detecting a Python interpreter escalating to root
A growing share of public PoCs finish with a one-line interpreter payload, and Python is the workhorse. Rather than matching an exact one-liner, we key on a uid_change to 0 where the responsible process is a Python interpreter running from a world-/user-writable working directory with a non-root parent.

event.category:process and event.type:change and event.action:uid_change and user.id:0 and not process.parent.user.id:0 and
not process.parent.group.id:0 and process.name:python* and
process.working_directory:(
/tmp* or /var/tmp* or /dev/shm* or /home/* or /run/user* or
/var/run/user* or /var/www*
) and
process.parent.working_directory:(
/tmp* or /var/tmp* or /dev/shm* or /home/* or /run/user* or
/var/run/user* or /var/www*
) and
process.command_line:*

As this activity is also known to hit on false positives, the new terms rule type was used to only alert on instances where the process.command_line hasn’t been seen on the host.id in the last five days.

With so many 2026 PoCs (Copy Fail, DirtyClone, CIFSwitch among them) shipped as Python, this catches the interpreter-driven finish generically, independent of the specific exploit. This maps to Suspicious UID Change to Root via Python and its Elastic Defend counterpart, which is slightly more restricted in terms of logic: Potential Privilege Escalation via Python Exploit.

More exec and elevate rules for Linux privilege escalation detection
We just described the most common exec and elevate relationships. However, several LPEs don’t trigger on the parent/descendant relationship, but require keying on parent → child or process → process relationships. You can find the whole list of public detection and endpoint rules below:

• General Privilege Escalation Sequence Detected

• UID Change to 0 from Unusual Process Executable

• UID Elevation from Previously Unknown Executable

• Potential Privilege Escalation via a Parent Process Sequence

• Potential Privilege Escalation via a Parent/Child Process Sequence

• Potential Privilege Escalation via a Suspicious UID Change

• Potential Local Privilege Escalation via a Suspicious Descendant Process

• Suspicious UID Change to Root via Python

• Potential Privilege Escalation via Python Exploit

The main difference between the detection and endpoint rule logic is the scope. Our endpoint detection and response (EDR) ruleset is generally optimized for a low false positive rate, over a high true positive rate. Because this can lead to false negatives, we “duplicate” the endpoint rule logic to detection rules with fewer to zero exclusions.

Detecting unshare and user namespace privilege escalation
Not every escalation runs straight at a setuid binary or a kernel bug in the host context. A large family of Linux LPEs first calls unshare(CLONE_NEWUSER) to gain capabilities inside a new user namespace and then uses that borrowed power to reach code paths (filesystems, mounts, networking) that were never meant to take untrusted input. Because that unshare step is shared across CIFSwitch, pedit COW, DirtyClone, and container escapes, we detect it independently of whichever bug follows.

We detect two behavioral red flags: correlating the namespace creation to a root transition, and flagging anomalous unshare usage on its own.

Detecting unshare followed by a root transition
The high-confidence form correlates a non-root unshare that creates a user namespace with a uid_change to 0 shortly after, under the same lineage.

sequence by process.parent.entity_id with maxspan=60s
[process where event.action == "exec" and event.type == "start" and
process.name == "unshare" and
process.args in ("-r", "-rm", "-m", "-U", "--user") and user.id != 0]
[process where event.action == "uid_change" and event.type == "change" and
user.id == 0 and process.parent.user.id != 0]

Match the namespace flags by substring rather than by exact token, so the combined short form is caught alongside the split -U -r -m form. This maps to Potential Local Privilege Escalation via Unshare.

The auditd variant additionally keys on the unshare syscall's namespace-flag argument, which is independent of how the flags were spelled on the command line.

sequence by host.id, process.parent.pid with maxspan=30s
[process where host.os.type == "linux" and
(
(
auditd.data.syscall == "unshare" and auditd.data.class == "namespace" and
auditd.data.a0 in (
"10000000", "50000000", "70000000", "10020000", "50020000", "70020000"
)
) or
(
process.name == "unshare" and
(
process.args in ("--user", "--map-root-user", "--map-current-user") or
process.args like ("-*U*", "-*r*")
)
)
) and user.id != "0" and user.id != null]
[process where host.os.type == "linux" and
user.id == "0" and user.id != null and
(
process.name in (
"su", "sudo", "pkexec", "passwd", "chsh", "newgrp", "doas", "run0",
"sg", "dash", "sh", "bash", "zsh", "fish", "ksh", "csh", "tcsh",
"ash", "mksh", "busybox", "rbash", "rzsh", "rksh", "tmux",
"screen", "node"
) or
process.name like ("python*", "perl*", "ruby*", "php*", "lua*")
)]

Tying the unshare to the subsequent uid_change keeps false positives low; sandboxing and container tooling call unshare constantly but rarely transition to root in the same lineage. This maps to Potential Privilege Escalation via unshare Followed by Root Process.

Detecting anomalous unshare usage without a root transition
Some namespace abuse is worth surfacing before any root transition, in particular, container escapes, where the goal is the host rather than uid 0. This form keys on unshare execution itself, filtered down to the parents that don’t legitimately use it.

process where host.os.type == "linux" and event.type == "start" and
event.action in ("exec", "exec_event", "start", "executed") and
process.name: "unshare"

The standalone unshare rule differs from the sequence rules by needing no root transition at all, which makes it a broader hunting and triage signal (and a noisier one), useful for the escape-to-host case that the correlation rules would never see. This maps to Namespace Manipulation Using Unshare.

GTFOBins abuse: Privilege escalation from a misconfigured SUID bit
The last category is the plain misconfiguration end of the spectrum: a binary that shouldn’t be setuid-root is, and dropping to a root shell is a one-liner straight out of GTFOBins. There’s no CVE or exploit chain, just a privilege that was granted and then abused.

Detecting known GTFOBins binaries running as root
A large, curated set of interactive-capable binaries (find, gdb, vim, dd, nmap, and many more) can spawn a shell or run a command, and when any of them ships setuid-root, that’s instant root. As this is a known list, we can use a large allowlist to detect this activity. We again use the ID versus real ID correlation to detect the execution of the SUID binary, in conjunction with a known SUID binary and a set of known noisy exclusions. The process listing is ordered from A-Z.

process where event.type == "start" and event.action == "exec" and (
(process.user.id == 0 and process.real_user.id != 0) or
(process.group.id == 0 and process.real_group.id != 0)
) and
process.name in (
"aa-exec", "ab", "agetty", "alpine", "ar", "arj", "arp", "as",
"ascii-xfr", "ash", "aspell", "atobm",
"base32", "base64", "basenc", "basez", "bc", "bridge", "busctl", "busybox",
[...]
"xdotool", "xmodmap", "xmore", "xxd", "xz",
"yash",
"zsh", "zsoelim"
)

This is the highest-volume, best-understood class, and a maintained name list keeps it cheap to run. It maps to Potential Privilege Escalation via SUID Binary.

Detecting GTFOBins edge cases: Capabilities and copied shells
While having this one allowlisted rule catches a lot of known bad behavior, it doesn’t suffice in scenarios where a capability, such as cap_setuid bit, is set instead of just a +s bit, or when a shell is copied to another directory and run from there. To catch some of these edge cases, we have several other rules in place:

• Potential Privilege Escalation via SUID Binary

• Shell Privileged Mode from Non-Standard Path with Root Effective User

• Potential Root Effective Shell from Non-Standard Path via Auditd

• Potential Privilege Escalation via Python cap_setuid

With this general layer in place, we’ll now take a look at some of 2026’s LPEs. For each showcased technique, we explain how it works, run and validate the detection of the public PoC, and note the rules that fire (the general-flow rules above, plus anything technique-specific).

Testing the framework against 11 public proof-of-concept exploits
To test whether this model survives changes in implementation, we ran 11 public exploit PoCs and two SUID misconfiguration cases. The summary records the first useful signal from each run, the privileged effect the test reached, and the rules that best explain the chain.

“No distinct precursor alert” means that the run produced no alert identifying the kernel primitive before the privileged effect. It does not mean that the PoC generated no userland activity.

With the general layer in place, the public PoCs become a validation set. We don’t need every exploit to look the same. We need the alerts to tell the same story: an unprivileged process prepares the ground and crosses a trust boundary, and then a root process appears.

Sometimes the earliest signal is a kernel primitive, such as AF_ALG plus splice(), and other times it’s namespace setup with unshare. Sometimes the trigger is quiet, and the only clean signal is the finish: a SUID helper, a Python process, or a shell suddenly running with effective uid 0. That’s the point of layering. Each PoC enters through a different door, but the investigation keeps folding back into the same model: precursor, root transition, and privileged execution.

Kernel page-cache and zero-copy corruption: The Copy Fail bug class
The page-cache corruption variants are the clearest example of why per-CVE detection is too narrow. Linux uses zero-copy paths, such as splice() and sendfile(), to move file-backed page-cache pages through kernel subsystems without copying them. When one of those subsystems writes in place without first honoring copy-on-write, an unprivileged user can corrupt the in-memory image of a privileged file. The file on disk may remain clean, but the cached version of /usr/bin/su, /bin/su, or another privileged target is no longer the version that the system administrator expects.

The lineage runs from DirtyCOW and Dirty Pipe into the 2026 wave: Copy Fail, DirtyFrag, DirtyClone, Fragnesia, pedit COW, and related variants. The interfaces differ, but the defender’s problem is the same. We want to catch the primitive where it’s stable, and we want to catch the privileged outcome when the primitive isn’t visible enough.

Copy Fail (CVE-2026-31431)
Copy Fail is the cleanest place to start because it gives us both sides of the story. The public PoC chains an AF_ALG socket with splice() to land a controlled write into a page-cache page and then uses that corruption against a privileged file. Public technical write-ups describe the vulnerable path as the authencesn AEAD implementation mishandling input manipulated through splice(), producing page-cache corruption through the crypto API.

In Kibana, this gives us a rare luxury: detection of the primitive and of the finish. The auditd layer can catch the non-root process producing a burst of socket(AF_ALG) calls interleaved with splice(), while Elastic Defend catches the behavioral outcome when the corrupted privileged file is executed.

The screenshot shows the expected mix: Potential Copy Fail (CVE-2026-31431) Exploitation via AF_ALG Socket alongside multiple SUID/SGID detections spread across security information and event management (SIEM) and EDR, where Suspicious SUID/SGID Utility Execution is the main EDR rule that fires when su runs with elevated effective privileges. This is the ideal case for layered detection; the kernel-specific signal tells us which exploit family we’re probably looking at, and the general-flow rules confirm that the host actually crossed into root.

DirtyFrag (CVE-2026-43284)
DirtyFrag is a useful counterexample. It reaches the same page-cache corruption outcome, but it doesn’t look like Copy Fail on the wire. Public research describes DirtyFrag as chaining the xfrm-ESP Page-Cache Write issue (CVE-2026-43284), with the RxRPC Page-Cache Write issue (CVE-2026-43500). The common failure is that shared socket-buffer fragments can reach in-place writers without the kernel first forcing a safe copy.

That changes the detection story. We shouldn’t expect the AF_ALG rule to fire, because this is no longer the Copy Fail primitive. What remains stable is the finish. In the lab run, the exploit process drives the corruption, and then /bin/su appears with root effective privileges, while the real user remains non-root.

The screenshot shows the general layer doing the work: Suspicious SUID Binary Execution, Potential Privilege Escalation via a Parent/Child Process Sequence, and the Elastic Defend Suspicious SUID/SGID Utility Execution alert. The trigger changed, but the host still had to execute a privileged binary in a suspicious lineage.

The full auditd configuration and queries for the AF_ALG and DirtyFrag primitive coverage are in the Copy Fail and DirtyFrag research. The next variants keep the same page-cache finish but move the trigger into different kernel interfaces.

Fragnesia (CVE-2026-46300)
Fragnesia is close enough to DirtyFrag that it belongs right next to it, but it adds a useful detection angle because the public PoC leaves more endpoint exhaust. The PoC targets skb_segment() in net/core/skbuff.c. During Generic Segmentation Offload (GSO) segmentation, skb_segment() propagates SKBFL_SHARED_FRAG from the head skb but not from a frag_list member that carries page-cache-backed fragments. Once that marker is lost, the resulting skbs can pass the ESP skip_cow guard and be decrypted in place over page-cache pages. The trigger is networking-heavy, namespaces, veth pairs, send(), splice(), Generic Receive Offload (GRO) coalescing, GSO segmentation, and an ESP-in-TCP receiver, but the primitive is the same shape we keep seeing: a controlled page-cache write that’s iterated until a SUID binary is corrupted and a root shell appears.

In Kibana, this one is louder than DirtyClone and more endpoint-friendly than a pure syscall primitive. The screenshot shows ./skb_segment_exploit driving the setup, followed by /usr/bin/su as the privileged finish. The alerts line up with that story. Two unique rules that triggered are related to the compilation of this exploit on the host, right before execution, and the fact that this exploit makes local network connections:

• Potential Privilege Escalation via Recently Compiled Executable

• Network Connection via Recently Compiled Executable

This is followed by similar SIEM and EDR rules triggering on the general LPE process:

• UID Elevation from Previously Unknown Executable

• Potential Privilege Escalation via SUID/SGID Proxy Execution (EDR and SIEM)

• Privilege Escalation via SUID/SGID

• Potential Privilege Escalation via a Suspicious UID Change

• Potential Privilege Escalation via a Parent Process Sequence

• File Creation in World-Writable Directory by Unusual Process

That’s the right detection outcome for this variant. We don’t need a narrow rule named after skb_segment() to get useful coverage. The kernel trigger is specialized and timing-sensitive, but the exploit still has to stage from a user-controlled context, exercise an unusual local networking path, corrupt a privileged target, and pivot through a SUID helper. The general-flow rules capture the root transition, while the recently compiled executable, world-writable file, network, and SUID/SGID alerts provide the analyst with sufficient context to recognize the Fragnesia-style path.

DirtyDecrypt / DirtyCBC (CVE-2026-31635)

DirtyDecrypt, also called DirtyCBC by the PoC authors, is another Copy Fail–style page-cache write, but the abused interface moves into RxRPC. The repository describes it as an rxgk page-cache write caused by a missing copy-on-write guard in rxgk_decrypt_skb(). The PoC comments spell out the failure mode: rxgk_decrypt_skb() builds an skb scatterlist and calls into Kerberos decryption without first forcing a safe copy, while the krb5enc AEAD template decrypts in place before the HMAC check. When the skb fragments are backed by page-cache pages, the failed decrypt still corrupts the cached file data.

In practice, this looks like a sibling of DirtyFrag rather than of Copy Fail. There’s no AF_ALG burst to lean on. The PoC sets up user and network namespaces, drives the RxRPC path over loopback, splices file-backed pages into the packet path, and repeatedly fires the decrypt primitive until the target bytes land. The checked PoC then targets a readable SUID-root binary, such as /usr/bin/su, backs it up under /tmp, corrupts the in-memory image with a tiny setuid(0) plus /bin/sh payload, and executes the target.

The screenshot shows the same layered outcome that we’ve seen across the page-cache family. The exploit process is ./dirtydecrypt, launched from a user-controlled working directory, and the privileged finish is /usr/bin/su. Coverage comes from the general-flow and SUID layers:

• General Privilege Escalation Sequence Detected

• Potential Privilege Escalation via SUID/SGID Proxy Execution (EDR and SIEM)

• Potential Privilege Escalation via Recently Compiled Executable

• File Creation in World-Writable Directory by Unusual Process

• Potential Privilege Escalation via a Suspicious UID Change

• Potential Privilege Escalation via a Parent Process Sequence

• UID Elevation from Previously Unknown Executable

• Privilege Escalation via SUID/SGID

DirtyDecrypt moves the primitive into RxRPC and Kerberos-style in-place decrypt, but the endpoint story is still familiar: a recently compiled local PoC stages from a writable path, corrupts a privileged file-backed page, and pivots through a SUID helper.

pedit COW (CVE-2026-46331)

pedit COW moves the same failure mode into traffic control. Instead of crypto sockets or ESP/RxRPC paths, the abused interface is the tc packet-editing action, act_pedit. The kernel computes a copy-on-write range before the edit loop, but that calculation can miss the runtime offset used by typed keys, leaving part of the write region outside the copied area. The result is another page-cache corruption path. NVD describes the issue as net/sched: fix pedit partial COW leading to page cache corruption, where tcf_pedit_act() computes the COW range once before the key loop and can leave part of the write region un-COW’d.

pedit COW looks nothing like Copy Fail in telemetry. There’s no AF_ALG burst. The PoC needs the traffic-control path and typically begins by obtaining namespace-local networking capability, such as CAP_NET_ADMIN, through unshare. From the detection side, that means we lean on the namespace precursor and the root outcome.

The screenshot shows this clearly. Some of the interesting alerts are the broader signals: file creation in a world-writable directory, UID elevation from a previously unknown executable, suspicious UID change, parent-process escalation, and SUID/SGID proxy execution. There’s currently no per-CVE tc rule, but the layered model still catches the behavior that matters: a user-controlled process sets up the path, corrupts the privileged image, and pivots into root execution.

DirtyClone (CVE-2026-43503)

DirtyClone is the quietest of the page-cache examples in the endpoint view. The bug sits in the Linux networking stack, where socket-buffer fragment transfer helpers fail to preserve the SKBFL_SHARED_FRAG marker. When that marker is lost, later in-place writers can treat shared, file-backed memory as private and write into page-cache-backed data. NVD describes CVE-2026-43503 as missing propagation of SKBFL_SHARED_FRAG through helpers such as __pskb_copy_fclone() and skb_shift(), which can let an unprivileged user write into the page cache of a root-owned read-only file through later in-place writers.

In our run, the public PoC doesn’t give us a loud, stable userland primitive to key on. It’s Python-driven, runs from a user-controlled working directory, and crosses into root. That makes it a perfect test for the general-flow layer.

The screenshot shows one alert: Potential Privilege Escalation via Python Exploit. That may look sparse compared to Copy Fail, but it’s an important result. It means that the framework still produced a signal when the implementation didn’t expose a useful per-CVE tell. We can enrich later if a stable syscall or interface pattern emerges, but we don’t need to wait for that to detect the root transition.

Taken together, the page-cache examples show the full range. Copy Fail gives us primitive-plus-outcome. DirtyFrag and Fragnesia show the same corruption model moving through networking paths, where SKB fragment handling, zero-copy, and in-place ESP processing do the damage. pedit COW moves the idea into traffic control. DirtyClone shows why the outcome layer has to stand on its own when the kernel trigger is quiet.

Exploits that start with unshare: CIFSwitch and OVSwrap

The next set of PoCs looks different because the attacker first changes the privilege context around the process. A large family of Linux LPEs begins with unshare(CLONE_NEWUSER), which gives an ordinary user capabilities inside a new namespace. Those namespace-local capabilities open kernel code paths in networking, filesystems, and mounts that weren’t designed with untrusted local users in mind.

This is also where kernel bugs and userspace helpers start to blur together. Some exploits use unshare to reach a kernel primitive. Others use it to build a hostile filesystem or mount namespace and then trick a privileged helper into trusting what it sees. For detection, unshare is valuable because it happens early and repeats across otherwise unrelated techniques.

CIFSwitch (CVE-2026-46243)

CIFSwitch is a trusted-helper bug reached through the kernel. The PoC abuses a missing validation in the cifs.spnego key type: an attacker calls request_key() with a forged key description, causing the kernel to invoke the root-owned cifs.upcall helper with attacker-controlled fields. With upcall_target=app, the helper enters the attacker's mount namespace and performs a getpwuid() lookup before dropping privileges: loading an attacker-controlled Network Security Services (NSS) library and executing code as root.

The important part is the handoff. The exploit starts with unshare to build the hostile namespace and then relies on a privileged helper to finish the escalation. That gives us several detection opportunities before and during the root transition.

The screenshot shows the expected spread:

• Potential Privilege Escalation via a Parent Process Sequence

• Namespace Manipulation Using Unshare

• Sudoers File Activity

• Potential Privilege Escalation via Python Exploit

• Potential Privilege Escalation via unshare and UID Change

• Suspicious Path Mounted

• Potential Local Privilege Escalation via Unshare

That’s the right shape for this technique. We aren’t depending on a rule named after CIFSwitch. We’re catching the setup, the suspicious namespace behavior, the mount activity, and the root transition. If the helper changes, the early namespace signal and the general escalation rules still give us coverage.

OVSwrap (CVE-2026-64531)

OVSwrap is a good example of the other side of namespace-based privilege escalation. Unlike CIFSwitch, where the namespace is used to construct an environment that a privileged userspace helper later trusts, OVSwrap uses a private user and network namespace to reach a vulnerable kernel interface directly. An ordinary user can run unshare -Urn, gain CAP_NET_ADMIN over the newly created network namespace, and create a private Open vSwitch (OVS) datapath without needing host-level CAP_NET_ADMIN.

The vulnerability is in the kernel's OVS action handling. OVS accepts nested Netlink actions from userspace and expands them into an internal action stream, but the nla_len field describing an individual Netlink attribute is only 16 bits wide. Before the fix, a generated nested action could grow beyond 65,535 bytes without being rejected. The stored length would wrap, causing later OVS parsing to resume from attacker-controlled data inside the generated action stream. The public PoC uses this to construct kernel read and targeted decrement primitives, locate a host-side process and its credentials, and modify its fsuid and fsgid until the process can write as root.

The endpoint story is particularly useful for detection because the kernel primitive itself is complex, but the setup and finish are not. The PoC is Python-driven and creates a private namespace with unshare; after corrupting the host-side writer's credentials, it writes a passwordless sudo rule and executes sudo -n bash.

In the lab run, this produced the following alerts:

• Potential Privilege Escalation via Python Exploit

• Namespace Manipulation Using Unshare

• Passwordless Sudo Probing

• Suspicious UID Change to Root via Python

• Potential Shadow File Read via Command Line Utilities (manual validation activity)

This is exactly the kind of exploit where the layered approach pays off. We don’t need an endpoint rule that understands malformed OVS CLONE actions, conntrack expansion, forged tunnel metadata, or the kernel decrement primitive. Instead, we see the stable behavior around it: a Python PoC enters a new namespace, unshare exposes a privileged kernel networking path, the process crosses from an ordinary user context into host-root capabilities, and the exploit finishes through passwordless sudo.

OVSwrap therefore complements CIFSwitch nicely. Both begin with an unprivileged user creating namespaces, but what happens next is very different: CIFSwitch hands control to a privileged helper, while OVSwrap attacks the kernel's OVS datapath and directly corrupts host credentials. The implementation changes; the namespace precursor and root-transition layer remain useful.

Privileged D-Bus and policy helpers
Not every helper-based LPE starts with a namespace. Some go straight at the services that grant controlled root access: sudo, polkit / pkexec, and privileged services reachable over D-Bus. These components are heavily used and well-audited, but they sit directly on the privilege boundary. One logic slip can turn a normal user request into root execution.

The upside for defenders is that the actors are named. We can key on specific binaries, services, and command-line shapes, in addition to the general root-transition layer.

ptrace_may_dream (busctl abuse)
ptrace_may_dream is a good example of a helper path that’s precise in telemetry. The technique talks to a privileged D-Bus system service directly with busctl. The escalation is driven by an unprivileged user invoking busctl --system call against a service that then performs a privileged action on the user’s behalf.

Because the tell is specific and rarely legitimate in normal workstation or server activity, detection can be tight.

The screenshot shows repeated Potential Privilege Escalation via Busctl System Call alerts, plus File Creation in a World-Writable Directory by Unusual Process. That’s a different detection shape from the page-cache examples, but the same investigation logic applies: suspicious precursor, privileged service interaction, and a path toward root-controlled behavior.

Privileged file-descriptor theft from trusted helpers
The previous examples all end in something easy to recognize: a process becomes root, a privileged service acts, or a SUID binary hands the user a shell. This pattern is slightly different. The attacker doesn’t need the helper to execute a command. They need it to open something privileged, drop credentials, and die slowly enough that the file descriptor can be stolen.

That’s the core of CVE-2026-46333. The bug sits in the kernel’s __ptrace_may_access() path. During process exit, there’s a short window when a task has already dropped its memory image but still has open file descriptors. Paired with pidfd_getfd(), that window lets an unprivileged process duplicate descriptors from a dying privileged process when the credential checks line up. Qualys described the impact as both credential disclosure and root-code-execution potential, with case studies against chage, ssh-keysign, pkexec, and accounts-daemon.

For defenders, this is an important variation on the normal LPE flow. A successful exploit may never create an obvious root shell. Instead, root-only material leaves the boundary: SSH host private keys, /etc/shadow, or an authenticated privileged IPC connection. The detection strategy, therefore, has to widen slightly. We still care about suspicious SUID/SGID execution and parent-child escalation, but we also care about non-root processes entering sensitive group context, especially from user-writable or freshly compiled paths.

ssh-keysign-pwn (CVE-2026-46333)
ssh-keysign-pwn targets OpenSSH’s ssh-keysign helper. The helper is interesting because it opens SSH host private keys before dropping privileges. The public PoC repeatedly spawns ssh-keysign, opens a pidfd for the child, races pidfd_getfd() across likely file descriptors, and checks whether any duplicated descriptor points to an ssh_host_*_key file. The repository describes the target directly: sshkeysign_pwn pulls SSH host private keys, while chage_pwn pulls /etc/shadow.

In the screenshot, the parent process is the user-controlled ./sshkeysign_pwn binary, and the privileged child is /usr/lib/openssh/ssh-keysign. The privilege shape is exactly what the SUID/SGID layer is built for: ssh-keysign runs with user.id:0, while the real user remains 1000, and the parent is a recently compiled executable in the user’s working directory. This results in the following rules triggering:

• Suspicious SUID Binary Execution

• Potential Privilege Escalation via SUID/SGID

• Potential Privilege Escalation via a Parent/Child Process Sequence

• Potential Privilege Escalation via Recently Compiled Executable

That’s enough to make the alert useful, even though the payload is a stolen descriptor, not a shell. The endpoint doesn’t have to prove that the SSH host key was printed to stdout. The host already showed the suspicious relationship that matters: a local PoC repeatedly drove a SUID-root helper that briefly held root-only secrets.

chage_pwn (CVE-2026-46333)
chage_pwn uses the same kernel primitive against a different helper and a more directly dangerous file. chage -l <user> opens account-aging data, including /etc/shadow, and then drops privileges. The PoC forks chage, opens a pidfd for the child, races pidfd_getfd() over candidate descriptors, looks for a duplicated descriptor pointing at /etc/shadow, and then reads from that descriptor.

This one is useful because it validates a slightly different detection idea. The screenshot shows repeated Potential Shadow Read via Unprivileged User alerts on ./chage_pwn root. The process is still running as the unprivileged user, but the meaningful transition is group-based: the process enters shadow context from a user-controlled executable path.

Plain SUID and SGID misconfiguration
The last examples are deliberately simple. A binary that shouldn’t be SUID-root is SUID-root, and the user runs it in the way that GTFOBins has documented for years. It’s the same finish we saw in the page-cache family, just without the corruption step. Copy Fail, DirtyFrag, pedit COW, and similar bugs often end by making a privileged binary behave like an attacker-controlled SUID helper. GTFOBins abuse starts there.

SUID abuse example: Root shell via find -exec
find can execute commands with -exec. When find is SUID-root, that executed command inherits the elevated context.

The screenshot shows that find runs with root effective privileges, while the real user is non-root, and the command line includes the shell execution path. The alert is Privilege Escalation via SUID/SGID.

Privileged-mode shell: Root from bash -p
Shells usually drop elevated privileges unless told not to. The -p flag keeps the privileged effective identity. If a SUID-root shell exists, or if a root-owned copy of bash is placed somewhere unusual with the SUID bit set, launching it with -p drops the caller directly into a root-capable shell.

The screenshot shows two useful detections: System Binary Copied or Moved, followed by Shell Privileged Mode from Non-Standard Path with Root Effective User. First, a system binary was copied into an unusual location (which is specific to how we set up this technique). Then the copied shell was executed in privileged mode.

This is the simplest form of the same pattern that we’ve been following throughout the section. A user-controlled path, a privileged execution context, and a root-capable process. Whether the attacker got there through AF_ALG, ESP/RxRPC, act_pedit, unshare, D-Bus, or a bad SUID bit, the endpoint story is still recognizable.

What this Linux privilege escalation detection framework covers
In this edition of our "Linux Detection Engineering" series, we built a layered framework for Linux local privilege escalation. The first layer detects the default flow every escalation shares: an unprivileged process executing from a writable path and becoming root, whether through a SUID helper, a self-elevating exploit, a suspicious descendant reaching root, a full exec-elevate-confirm sequence, a root shell from a nonstandard path, or an interpreter one-liner. The second layer adds bug-class coverage across the kernel page-cache corruption family, namespaces and capabilities, trusted-helper abuse, sudo and polkit, privileged D-Bus services, and plain SUID/SGID misconfiguration.

The value of this framework is durability. The 2026 surge produced many new CVEs, but they largely reused a handful of ideas and all ended in the same observable root transition, so outcome-oriented detection held up as the PoCs multiplied. It doesn’t claim to catch every possible LPE, but it gives defenders broad, resilient coverage of how escalations actually behave and a clear place to slot in each new technique as it appears.

ATOMIC MACOS (AMOS) STEALER INFECTION

11.9.2026  MALWARE TRAFFICS 

NOTICE:

• Zip files are password-protected.  Of note, this site has a new password scheme.  For the password, see the "about" page of this website.

NOTES:

• My thanks to Dani [Varys] Z who let me know abut the fake macOS software page through a comment on LinkedIn.

ASSOCIATED FILES:

• 2026-09-10-AMOS-Stealer-notes.txt.zip   1.9 kB   (1,884 bytes)

• 2026-09-10-AMOS-Stealer-infection-traffic.pcap.zip   3.5 MB   (3,476,742 bytes)

• 2026-09-10-files-from-AMOS-Stealer-infection.zip   838.7 kB   (838,718 bytes)

IMAGES

Shown above: Fake macOS software page.

Shown above: Text from the fake software page pasted into a macOS Terminal window.

Shown above: Traffic from the infection filtered in Wireshark.

XWORM INFECTION

11.9.2026  MALWARE TRAFFICS 

NOTICE:

• Zip files are password-protected.  Of note, this site has a new password scheme.  For the password, see the "about" page of this website.

ASSOCIATED FILES:

• 2026-09-08-XWorm-notes.txt.zip   0.9 kB   (9,38 bytes)

• 2026-09-08-XWorm-post-infection-traffic.pcap.zip   4.9 kB   (4,853 bytes)

• 2026-09-08-XWorm-files.zip   452.9 kB   (452,931 bytes)

2026-09-08 (TUESDAY): XWORM INFECTION

EMAIL INFORMATION:

- Return-Path: amedrano.tornillo@gmail[.]com
- Received: from gmail[.]com (unknown [217.60.195[.]100])
  by [information removed]; Tue, 08 Sep 2026 17:43:14 +0000 (UTC)
- From: Alejandra Medrano (amedrano.tornillo@gmail[.]com)
- To: [information removed]
- Subject: ENVIO DOCUMENTOS FACTURA 4558
- Date: 08 Sep 2026 10:43:13 -0700

ATTACHED FILE:

- SHA-256 hash: 9b4e654a8435d91c7f4e24e7fd844cbbb62328131b0065bc5a534c6e948c02c5
- File size: 141,703 bytes
- File type: RAR archive data, v5
- File name: PAGO-ENVIO DOCUMENTOS FACTURA 4558.LZH

EXTRACTED MALWARE FOR XWORM:

- SHA-256 hash: 5ba1eee1204710adfe1963b730de79c7a8089b173e811052e7be464fc5da1a1d
- File size: 207,267 bytes
- File type: ASCII text, with very long lines, with CRLF, LF line terminators
- File name: PAGO-ENVIO DOCUMENTOS FACTURA 4558.js
- Sandbox analysis: https://www.joesandbox.com/analysis/1970315
- Sandbox analysis: https://tria.ge/260908-ymwaaagp3s/
- Sandbox analysis: https://app.any.run/tasks/7654b48a-cf1a-41f7-a65e-73d82381401c

XWORM C2 TRAFFIC:

- tcp[:]//43.228.157[.]141:7007/

NOTES:

- The infection did not survive a reboot on my infected Windows host.

Scans for Proxmox Servers

10.9.2026  SANS  Vulnerebility

About a week ago, Proxmox published an advisory revealing a vulnerability in older versions of Proxmox VE, its flagship Virtual Environment product. The vulnerability only affects version 7, which has not been supported for a couple of years now.

But it appears that the vulnerability may have caught the attention of some attackers and researchers. We do see a bump in scans for port 8006, and also some additional brute force traffic. For example, brute force requests like:

POST /api2/json/access/ticket HTTP/1.1
Host: [redacted]:8006
User-Agent: Go-http-client/1.1
Content-Length: 37
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip
 

password=Ww778899&username=root%40pam

The PVE proxy log will log failed login attempts with a 401 status code:

::ffff:62.60.130.193 - - [09/09/2026:15:26:14 +0000] "POST /api2/json/access/ticket HTTP/1.1" 401 50
::ffff:62.60.130.193 - - [09/09/2026:15:28:04 +0000] "POST /api2/json/access/ticket HTTP/1.1" 308 18
::ffff:62.60.130.193 - - [09/09/2026:15:28:08 +0000] "POST /api2/json/access/ticket HTTP/1.1" 401 50
::ffff:62.60.130.193 - - [09/09/2026:15:29:49 +0000] "POST /api2/json/access/ticket HTTP/1.1" 308 18
::ffff:62.60.130.193 - - [09/09/2026:15:29:52 +0000] "POST /api2/json/access/ticket HTTP/1.1" 401 50
::ffff:62.60.130.193 - - [09/09/2026:15:31:33 +0000] "POST /api2/json/access/ticket HTTP/1.1" 308 18
::ffff:62.60.130.193 - - [09/09/2026:15:31:36 +0000] "POST /api2/json/access/ticket HTTP/1.1" 401 50

You may also see the less commonly used 308 status code if the attacker does not use TLS on their first attempt and instead sends a POST request (as shown above). A 308 access code allows a client to change the request method after following the redirect. 301 and 302 status codes require the same method for the follow-up request.

Other scans I have seen:

Classic Fingerprinting

/pve2/images/logo-128.png???????

And a POST request to /api2/extjs/access/ticket. This endpoint behaves differently from the prior endpoint. It always returns 200, but the JSON payload will contain the login failed messages. These are trickier to analyze because the proxy log does not indicate the outcome of authentication. A return payload size of 77 bytes should indicate failure.

Redtail Payload Analysis

10.9.2026  SANS  Security

Following a RedTail Linux Payload from DShield to Dynamic Analysis

During monitoring of my DShield honeypot, I observed an attacker uploading a collection of Linux executables targeting several processor architectures. The files included ARM, ARM64, i686, RISC-V and x86-64 variants named as part of a RedTail deployment package. Rather than relying only on static indicators or public threat-intelligence results, I extracted the captured payloads from Cowrie and analyzed the x86-64 variant in an isolated malware-analysis environment.

The x86-64 sample analyzed in this article has the following SHA-256 hash:
63be5f38b520b3143732962a5f8fec1f9abd1f483dbc741ed324e58f955dd35e

Dynamic analysis showed that the payload did considerably more than simply execute. It changed its visible process identity, terminated other processes, killed one of the filesystem-monitoring processes used during the experiment, and created a TCP listening socket. A matched pair of pre- and post-execution memory images was also acquired from the Proxmox hypervisor to preserve the malware's runtime state independently of the infected guest.

From Cowrie Upload to Malware Sample

The original files were recovered from the Cowrie download directory on the DShield honeypot and copied into a separate folder named after the event.code on the DShield SIEM “attack-a7fc773a9f1a”. The attack delivered multiple architecture-specific versions of the same malware family together with shell scripts responsible for deployment and cleanup.

The recovered set included variants for:

The associated deployment script inspected the host architecture and selected the appropriate RedTail executable. Static inspection of the x86-64 binary identified it as a statically linked ELF executable. Strings extracted from the sample also contained an indication that it had been processed with the UPX executable packer.

For the controlled experiment described here, I selected redtail.x86_64, matching the architecture of the Ubuntu analysis VM.

Isolated Analysis Environment

The malware was executed inside an Ubuntu 24.04 virtual machine hosted on Proxmox. The victim was assigned:
10.66.66.10/24

and was connected only to an isolated malware-analysis network.

An INetSim server at:

10.66.66.2
provided simulated network services. The victim had no default route to the Internet. Before execution, connectivity to INetSim was verified while attempts to reach an external address such as 8.8.8.8 returned Network is unreachable.

This design allowed the malware to encounter DNS and network services without allowing it to communicate with real external infrastructure.

Several monitoring mechanisms were started before staging the sample. These included auditd syscall and filesystem rules, inotifywait filesystem monitoring, continuous process and socket sampling, journal and kernel logging, tcpdump on both the victim and INetSim systems, and strace around the actual malware execution.

In addition, guest memory was acquired from outside the infected system using QEMU's dump-guest-memory functionality on the Proxmox host.

Detonating the redtail.x86_64 Elf executable only (Setup.sh and Clean.sh were not ran)

There were three runs (Run 001.1, Run 001.2 and Run 002) of the malware detonation executed, with the VM reverted back to original pre-detonation state between RUN 001 and RUN 002. In RUN 001, the malware file was detonated twice. RUN 001 was run as user privileges but RUN 002 was run as root.

This report will focus on analyzing RUN 002 with comparisons made to RUN 001.1 and 1.2 to establish similiarities and differences between the runs.

Analysing Run 002, two memory images were collected:

vm610-baseline-pre-redtail.elf
vm610-post-redtail.elf

Both images were approximately 6 GB and were independently SHA-256 verified after acquisition. The baseline image was collected after all monitoring processes had been started but before the malware was staged, making the two images suitable for later differential analysis.

Controlled Execution

For the second experiment, the malware was executed directly with the argument observed during the earlier investigation:

redtail.x86_64 ssh
strace confirmed successful execution:
execve("/analysis/run-002/sample/redtail.x86_64",
       ["/analysis/run-002/sample/redtail.x86_64", "ssh"],
       ...) = 0

This was important because it established that the subsequent behavior belonged to a successfully executing instance of the recovered Cowrie payload rather than to a failed launch or unrelated process.
Two RedTail-backed processes remained running after execution:

PID 10395
PID 10404

Both /proc/<PID>/exe links resolved to:
/analysis/run-002/sample/redtail.x86_64
and hashing those executable mappings produced the same SHA-256 as the original recovered sample.
Despite this, neither process presented itself as redtail.x86_64.
Instead, both appeared as:

php-fpm: pool www

Process Masquerading

The strace output captured the mechanism RedTail used to alter its visible process name:
prctl(PR_SET_NAME, "php") = 0
The successful return value demonstrates that RedTail deliberately modified its task name.
The result was a process that appeared in ordinary process listings as a legitimate PHP-FPM worker:
php-fpm: pool www
while /proc/<PID>/exe continued to identify the executable as the original RedTail sample.

This creates a useful forensic distinction. A process listing by itself could suggest that PHP-FPM was running on the system, while examining /proc/<PID>/exe and hashing the mapped executable revealed that the apparent PHP process was actually the RedTail binary.

This behavior was also consistent with an earlier experimental run in which surviving RedTail processes presented themselves using a PostgreSQL-like process name. The repeated observation suggests that RedTail uses legitimate-looking service names to make malicious processes less conspicuous in routine process inspection.

Process Termination and Monitoring Interference

One of the clearest behavioral findings from Run 002 was RedTail's use of SIGKILL.
Before execution, the automated readiness check confirmed that the filesystem-monitoring process was active:   

[OK] inotify PID 1199

During malware execution, strace recorded:

kill(1199, SIGKILL) = 0
The return value of zero indicates that the signal was successfully delivered.
After execution, the same readiness check reported:
[!!] inotify not running

This provides a direct evidence chain:

inotifywait running
        ↓
RedTail calls kill(1199, SIGKILL)
        ↓
kernel reports success
        ↓
inotifywait no longer running

RedTail also issued successful SIGKILL calls against several additional PIDs during the same execution.

An important limitation must be stated here: Run 002 executed RedTail with root privileges. This gave the malware sufficient permission to terminate the root-owned monitoring process. In the earlier Run 001 experiment, a lower-privileged RedTail process attempted to terminate a root-owned monitor but received EPERM. Therefore, the successful termination observed in Run 002 demonstrates RedTail's process-killing behavior, while the ability to kill the monitoring process specifically depended on the privileges under which the sample was executed.

Network Activity, Listener, and INetSim Observations
After execution, surviving RedTail process PID 10395 was observed listening on 0.0.0.0:39983

Although the process appeared as php-fpm: pool www, /proc/10395/exe resolved to the analyzed redtail.x86_64 sample. No packets involving TCP/39983 were observed in the Run 002 victim PCAP, so the purpose of the listening socket could not be determined.  

While INetSim and packet capture initially showed no obvious RedTail outbound traffic, auditd revealed that PID 10395 attempted multiple external connect() calls on TCP port 853. Destinations included 1.1.1.1, 1.0.0.1, 8.8.8.8, 8.8.4.4, 9.9.9.9, 9.9.9.10, and several additional addresses. TCP/853 is commonly associated with DNS-over-TLS, and most of the observed destinations were public DNS resolver infrastructure.

Two addresses, 80.152.203.134 and 109.91.184.21, did not clearly correspond to known public resolver services during the investigation. Reverse-DNS information showed that 80.152.203.134 resolved to mail3.kekew.info and was allocated to Deutsche Telekom AG (AS3320), while 109.91.184.21 resolved to ip-109-091-184-021.um37.pools.vodafone-ip.de and belonged to a Vodafone GmbH static B2B customer pool (AS3209). Both addresses were contacted by the same RedTail-backed process on TCP/853, with the connection attempts failing with ENETUNREACH. Their specific role in the observed activity could therefore not be confirmed, and they were retained as anomalous resolver candidates rather than classified as malicious infrastructure.

Because the victim was deliberately configured without a default Internet route, every external connection attempt failed with ENETUNREACH before a packet could leave the host. This explains why these attempts were absent from both the victim PCAP and INetSim logs. In this case, endpoint auditing revealed network intent that network monitoring alone could not observe.

Differential analysis of the pre- and post-execution memory images also found several of the TCP/853 destinations only in post-execution memory. However, examination of the surrounding RAM showed that these strings belonged to cached audit records containing the RedTail PID, executable path, destination address and failed connect() result. The memory findings therefore corroborated the auditd evidence but were not treated as proof that RedTail stored its resolver list directly in plaintext process memory.

The same TCP/853 resolver sequence was reproduced in both separate RedTail executions. Several destinations corresponded to established DNS-over-TLS services, strongly supporting the interpretation that this sequence forms part of RedTail's resolver-selection or encrypted DNS initialization behaviour.

A RedTail-backed TCP listener was observed during both executions, but the listening port differed between runs (40219 in Run 001 and 39983 in Run 002). No traffic involving either listener was observed during the corresponding packet captures. This suggests that the listener port may be dynamically selected, although two observations are insufficient to determine the exact selection mechanism.

Filesystem Changes and Persistence

Run 002 provided direct evidence of persistence. Immediately after execution, the RedTail-backed process spawned a shell that first removed the existing root crontab and then installed a new entry containing @reboot <RedTail executable>. The resulting /var/spool/cron/crontabs/root file was absent from the pre-execution filesystem baseline but present following execution. This established a straightforward reboot-persistence mechanism: RedTail would be relaunched whenever the infected host restarted.

RedTail also spawned a separate shell that invoked iptables -F and attempted to insert an INPUT rule allowing TCP traffic to port 39983. This was the same port on which the surviving masqueraded RedTail process was listening. The behavior therefore suggests that RedTail attempted to expose its newly created listener through the host firewall. Audit and process-accounting evidence confirm that both iptables commands were executed as root; however, because no post-execution firewall ruleset or command termination status was preserved, successful application of the firewall changes could not be independently verified.

Run 001 showed the same persistence and firewall logic while RedTail was executed as the unprivileged victor58 account. Instead of creating a root crontab, RedTail removed and replaced the current user's crontab, resulting in the creation of /var/spool/cron/crontabs/victor58 with an @reboot entry pointing to the RedTail executable. This demonstrates that the cron persistence mechanism does not depend on root privileges; RedTail installs persistence under whichever account is executing the malware. Run 001 contained two separate executions of the sample, and each execution repeated this behavior. The corresponding firewall commands attempted to flush the ruleset and allow inbound access to the dynamically selected listener ports 39539 and 40219. Because these commands were executed as UID 1000 without root privileges, successful firewall modification was not established and would normally require additional privileges.

Across the two runs, the persistence behavior was therefore consistent while the resulting crontab depended on execution context: Run 001 persisted through the victor58 user crontab, whereas Run 002 persisted through the root crontab. The listener ports also differed across executions (39539, 40219, and 39983), further supporting the observation that RedTail selects a high-numbered listening port dynamically rather than relying on a single fixed port.

Process Masquerading and Listener Establishment

RedTail established a high-numbered TCP listener while disguising its process identity. During the first Run 001 execution, RedTail changed its process name to php, and the surviving malware process, PID 147999, was subsequently observed listening on 0.0.0.0:39539. Audit records from the same execution showed a child process invoking iptables -I INPUT -p tcp --dport 39539 -j ACCEPT, directly linking the firewall-modification attempt to the dynamically selected listener port. The iptables executable was successfully launched, although the preserved evidence does not confirm that the non-root process successfully applied the firewall rule.

The behaviour was reproduced with different values across subsequent executions. The second Run 001 execution masqueraded using a PostgreSQL-like process name and listened on TCP port 40219, while the root-privileged Run 002 execution used the process name php, a php-fpm: pool www process title, and listened on TCP port 39983. The differing ports across the three executions indicate dynamic high-port selection rather than reliance on a fixed listening port. In each case, RedTail's firewall command referenced the corresponding selected listener port.

RUN 001.1 Pictures

RUN 001.2 Pictures

RUN 002 Pictures

Summary

Host Discovery and System Profiling

Immediately after execution, RedTail performed extensive host profiling through Linux /proc and /sys interfaces. It queried processor characteristics, CPU topology and cache configuration, system memory, NUMA layout, huge-page availability, GPU information, kernel boot parameters, and DMI hardware identifiers.

Several of these queries were capable of identifying the analysis environment as virtualized. In Run 002, the returned data included the hypervisor CPU flag, QEMU system and chassis vendor values, SeaBIOS, and a Q35 virtual-machine product identifier. Despite receiving these virtualization indicators, RedTail continued executing its persistence, listener-creation and network-initialization routines.

To determine whether this profiling was incidental or part of a consistent initialization routine, the same query set was compared across both RedTail executions in Run 001 and the root-privileged execution in Run 002.

Raw Log Screenshot Snippets

Processed Logs Screenshot Snippet

RedTail Host Profiling Queries — Run 002

RedTail first queried /proc/cpuinfo and /proc/cmdline, obtaining processor, architecture and kernel information. The CPU information identified the virtual machine as exposing an AMD Ryzen 7 6800H processor with four visible CPUs and included the hypervisor CPU flag.

The sample then enumerated the topology of CPUs 0 through 3. It queried core IDs, CPU maps, package and die relationships, and CPU availability. This allowed it to identify the number and arrangement of available processors.

RedTail also performed unusually detailed cache enumeration. It queried the type, level, size, line size, number of sets, and sharing relationships of the available L1, L2 and L3 caches. It continued checking additional cache indexes until the kernel returned ENOENT, indicating that no further cache levels were present.

This behaviour shows that RedTail was not limited to simply determining the processor model or CPU count. It collected detailed information about the resources and topology available to the process.

CPU topology

CPU cache profiling

NUMA and memory profiling

RedTail queried /proc/meminfo to determine total and available system memory, swap configuration and huge-page availability. In Run 002, the VM exposed approximately 6 GB of RAM and 4 GB of swap, while no huge pages were currently allocated.

The sample also queried NUMA information under /sys/devices/system/node. It identified a single NUMA node, obtained the CPUs associated with that node, examined node-specific memory usage, and checked both 2 MB and 1 GB huge-page configurations. RedTail additionally attempted to query NUMA bandwidth and latency interfaces, although these returned ENOENT because the interfaces were unavailable in the VM.

The detailed CPU, cache, NUMA and huge-page enumeration resemble resource-suitability profiling that could be useful to a computationally intensive workload. However, the observed system calls 
alone do not establish exactly how RedTail used this information.

Hardware and virtualization profiling

RedTail queried multiple DMI identifiers under /sys/devices/virtual/dmi/id/. It also retrieved the VM's product_uuid when executing with root privileges.

These results show that RedTail queried information sufficient to identify the system as a QEMU virtual machine. The evidence does not establish that the malware performed anti-VM evasion or terminated based on these values; in this experiment, it continued execution despite receiving them.

Host Profiling Comparison Across Run 001 and Run 002

The host-profiling behaviour was highly reproducible.
Run 001 contained two separate non-root executions of RedTail, and each produced 180 extracted host query/reply records. Run 002 executed the same sample as root. After normalizing the process-specific /proc/<PID>/cpuset path, the unique host-information query sets from all three executions were identical and produced the same SHA-256 hash.

This demonstrated that RedTail consistently queried the same categories of information across all three executions:

• CPU and processor capabilities
• CPU topology
• cache configuration
• system memory
• NUMA topology
• huge-page configuration
• GPU information
• kernel configuration
• DMI hardware and virtualization identifiers

1. Identify which Run 001 trace files performed the host profiling

2. Extract PATH | REPLY from every matching RedTail trace

3. Then list what was created:

4. Make a clean list of only the paths queried

5. Compare the two Run 001 executions

6. Compare Run 001 with Run 002

Create its path-only version for Run 002, same formatting as applied to Run 001:

Then compare it against Run 001:

7. Normalizing the process-specific /proc/<PID>/cpuset pathname

8. Comparing all 3 runs query paths again with sha256 hashes of the files.

Result: All the same query paths being run.

After which, a comparison of the returned values was performed. A comparison was taken between the two non-root Run 001 executions:

The comparison of the returned values showed that most differences were simply caused by changing system state. For example, free and available memory differed between executions while the same /proc/meminfo query was performed each time.

The comparison between Run 001 and Run 002 were more interesting because Run 001 was non-root while Run 002 was root directly, the differences were related to execution privilege. During the non-root Run 001 executions, the following DMI queries returned EACCES:

chassis_serial | ERROR: EACCES
product_serial | ERROR: EACCES
product_uuid   | ERROR: EACCES

During root-privileged Run 002, RedTail queried exactly the same paths, but access succeeded:

chassis_serial | [empty]
product_serial | [empty]
product_uuid   | 770cb473-61eb-4f56-9777-d9e44d8ad48f

The second Run 001 execution gives the same non-root result, strengthening the finding.

This suggests that RedTail did not adapt its discovery routine according to privilege. Instead, it attempted the same enumeration sequence and obtained additional information when its execution context permitted access.

Root Privileges Query Output (No error returned):

Profiling Summary

The analysis showed that host and resource profiling is a consistent part of RedTail's initialization behaviour. Across three separate executions—two non-root executions in Run 001 and one root execution in Run 002—the malware queried an identical normalized set of host-information paths.

RedTail collected considerably more information than was required simply to identify the operating system. It enumerated CPU topology and cache geometry, system and NUMA memory, huge-page configuration, GPU availability, kernel parameters and DMI hardware identifiers. Execution privilege affected what information the operating system returned, but not which resources RedTail attempted to query.

Across all executions, RedTail obtained clear indicators that the analysis host was virtualized, including the hypervisor CPU flag, QEMU vendor strings, SeaBIOS and the Q35 virtual-machine identifier. Despite receiving these signals, the sample continued with cron persistence, listener creation, firewall-manipulation attempts and network initialization. This suggests that obvious virtualization indicators alone were not sufficient to alter or halt RedTail’s observed runtime behaviour. One possible explanation is that virtualization by itself is no longer a reliable indicator of a malware-analysis sandbox, because similar characteristics are also common in legitimate VPS and cloud-hosted Linux environments. The purpose of these virtualization-related queries therefore cannot be conclusively attributed to sandbox evasion.

Process Termination and Defense Evasion

During Run 002, RedTail enumerated running processes through /proc, resolved their executable paths, and inspected command-line arguments before selectively issuing SIGKILL. The malware successfully terminated PID 1199, an inotifywait process used by the analysis environment to monitor filesystem changes. It also successfully killed the timeout process supervising the tracing session, along with two sudo processes associated with the script used to launch the experiment. In each of these cases, the kill() system call returned 0, confirming that the termination request succeeded.

RedTail also identified /usr/bin/strace, read the command line showing that it was tracing the RedTail executable, and then issued SIGKILL against the strace process. The trace terminated while recording this system call, so its return value was not preserved. Nevertheless, the sequence provides strong evidence that RedTail actively interfered with the instrumentation used to observe its behaviour during the root-privileged execution. The available dynamic evidence confirms analysis-tool disruption, although it does not yet establish the exact criteria RedTail used to decide which processes to terminate.

The same process-enumeration and termination behaviour was reproduced during the two non-root executions in Run 001. In both executions, RedTail identified the root-owned inotifywait process used to monitor filesystem changes, read its command line, and attempted to terminate it with SIGKILL. These attempts returned EPERM, demonstrating that the non-root execution context prevented RedTail from terminating the root-owned monitor.

Process terminated as Root:

However, non-root privileges did not prevent RedTail from interfering with analysis processes running under the same user context. During the second Run 001 execution, RedTail identified and successfully terminated the timeout process supervising its strace session. It then identified /usr/bin/strace, read the command line showing that the tracer was monitoring the RedTail executable, and invoked SIGKILL; the trace terminated before the system-call return value could be recorded. The second execution also successfully terminated PID 147999, the surviving RedTail process from the first execution, suggesting possible previous-instance cleanup or single-instance enforcement.

Process terminated as User:

Together, Runs 001 and 002 show that RedTail's process-disruption routine operates regardless of privilege, while its effectiveness depends on the ownership and privilege level of the target process. Root execution enabled RedTail to terminate the root-owned filesystem monitor, whereas non-root execution was restricted to processes it was permitted to signal.

Overall Conclusion

Dynamic analysis of the RedTail sample revealed a consistent sequence of host discovery, persistence, process manipulation, network initialization, and defensive interference across both privileged and unprivileged executions. Although individual values such as process names and listening ports changed between executions, the underlying behavior was highly reproducible.

RedTail performed extensive host profiling through Linux /proc and /sys interfaces, enumerating processor characteristics, cache topology, memory, NUMA configuration, huge-page availability, and DMI hardware information. The same normalized set of host-information paths was queried across both Run 001 executions and Run 002. The sample also obtained explicit virtualization indicators, including the hypervisor CPU flag, QEMU identifiers, SeaBIOS, and a Q35 virtual-machine product name, but continued execution despite receiving this information. Execution privilege affected the information available to the malware but did not substantially alter its discovery routine.

Persistence was established through the current execution account's crontab using an @reboot entry pointing to the RedTail executable. Consequently, the non-root Run 001 execution created persistence for victor58, while the root-privileged Run 002 execution created root-level cron persistence. RedTail also attempted to manipulate the host firewall by flushing existing rules and inserting an INPUT rule for its dynamically selected TCP listener. The selected listener changed between executions—TCP ports 39539, 40219, and 39983 were observed—while the corresponding iptables command referenced the matching port in each case. Firewall modification was confirmed as attempted, although the preserved evidence does not establish successful rule application in every execution.

RedTail additionally disguised its running processes. Observed process names included php and a PostgreSQL-like postgres: user ..., while Run 002 also presented a process title of php-fpm: pool www despite the executable remaining redtail.x86_64. The masquerading processes owned the dynamically selected TCP listeners, demonstrating that the altered identities were associated with the surviving malware processes rather than unrelated applications.

A particularly significant finding was RedTail's interference with the analysis environment. The malware enumerated running processes, inspected executable paths and command-line arguments, and selectively issued SIGKILL. During non-root Run 001, attempts to terminate the root-owned inotifywait filesystem monitor failed with EPERM; however, RedTail remained capable of disrupting analysis processes that it had permission to signal, including the timeout process supervising its tracing session. During root-privileged Run 002, the same inotifywait monitor was successfully terminated. RedTail also identified /usr/bin/strace, read the command line showing that it was tracing redtail.x86_64, and issued SIGKILL; the trace terminated while recording that operation. These observations demonstrate that the process-disruption routine was present regardless of privilege, while its effectiveness depended on the privileges and ownership of the target process.

Network analysis identified repeated connection attempts to multiple external IP addresses on TCP port 853. The same target sequence appeared across Run 001 and Run 002, supporting its association with RedTail rather than unrelated host activity. Because the analysis VM deliberately had no default Internet route, these connections failed with ENETUNREACH and did not leave the host. The use of TCP/853 is consistent with DNS-over-TLS infrastructure, although the isolated environment prevented observation of any successful protocol exchange and therefore does not establish the ultimate purpose of those connections.

Static examination of the accompanying clean.sh script identified additional cleanup functionality targeting cron entries, shell-startup files, temporary directories, miner-related services, and suspicious process names. However, the script was not observed executing during either dynamic-analysis run. Its functionality should therefore be treated separately from behavior directly demonstrated by redtail.x86_64.

Overall, the experiments show RedTail as a Linux threat that combines persistent execution, extensive host profiling, process masquerading, dynamically selected listening services, attempted firewall manipulation, repeated external network initialization, and active interference with monitoring and analysis processes. Running the sample under both non-root and root contexts was particularly valuable: the experiments demonstrated that RedTail largely follows the same behavioral sequence regardless of privilege, while elevated privileges substantially increase the effectiveness of actions such as accessing protected host identifiers, modifying privileged resources, and terminating root-owned monitoring processes.

Limitations of Analysis:

• External TCP/853 connections could not complete because the victim intentionally had no Internet route.
• No inbound interaction with the RedTail listeners was observed, so their higher-level protocol/function was not established.
• Successful execution of iptables via execve() does not by itself prove that every firewall-rule change was successfully applied.
• clean.sh and setup.sh was analyzed statically and was not observed executing during Runs 001 or 002.

Indicators of Compromise

MITRE ATT&CK Mapping

Other Summary Findings – Supporting RedTail File Deployment and Clean Up

Static Analysis of SETUP.SH *Not Executed in any of the runs*

Static examination of setup.sh identified a multi-architecture staging and execution mechanism for RedTail. The script determines the victim's processor architecture and selects an associated payload for x86-64, x86, ARM or RISC-V systems. It enumerates user-owned writable directories and examines filesystem noexec settings to identify a suitable staging location, with /tmp, /var/tmp and /dev/shm included as fallback locations. The selected RedTail binary is copied into a randomly generated dot-prefixed filename, marked executable and launched with the argument ssh. Following execution, the script deletes the more readily identifiable redtail.* architecture-specific payload files from both the staging and original directories. This combination of malware relocation, hidden-file staging and artifact cleanup appears intended to reduce the visibility of the deployed executable. Static analysis does not, by itself, establish that setup.sh executed during the controlled dynamic-analysis runs.

Static Analysis of CLEAN.SH *Not Executed in any of the runs*

Static analysis of the accompanying clean.sh script revealed functionality designed to remove common Linux malware persistence mechanisms and terminate suspicious processes. The script first disables and stops a service named c3pool_miner. It then removes immutable and append-only attributes from cron files before filtering user and system cron configurations for commands containing strings such as wget, curl, /dev/tcp, /tmp, .sh, nc, bash -i, sh -i, and base64 -d.

The cleanup extends across user crontabs, /etc/crontab, cron scheduling directories, /etc/anacrontab, and the current user's crontab. The script additionally removes the top-level contents of /tmp, /var/tmp, and /dev/shm, and applies the same filtering routine to .bashrc, .bash_profile, and .profile. These actions are consistent with an attempt to remove scheduled-task, shell-startup, and temporary-file persistence.

Finally, the script attempts to terminate processes associated with unusual names including /bin/-bash, systemtd, and /usr/bin/.sh using SIGKILL. The name systemtd resembles the legitimate systemd service name and may represent an attempt to target a masquerading process. However, the available evidence does not establish that these filenames belong specifically to the RedTail sample analyzed in Runs 001 and 002.

The script was not observed executing during either dynamic-analysis run. Its contents should therefore be treated as static functionality associated with the recovered script rather than behaviour directly observed from redtail.x86_64.

SETUP.SH File Contents

CLEAN.SH File Contents

[1] https://www.inetsim.org/index.html
[2] https://github.com/bruneaug/DShield-SIEM/tree/main
[3] https://www.sans.edu/cyber-security-programs/bachelors-degree/

September 2026 Microsoft Patch Tuesday

9.9.2026  SANS  OS

This month, Microsoft released patches for a record-breaking 973 vulnerabilities, including 113 rated critical. It is by far the largest Patch Tuesday to date, well ahead of the previous high of 664 set in July 2026. Two vulnerabilities are listed as exploited in the wild, while none were publicly disclosed before Patch Tuesday. Notable fixes include Windows privilege escalation and critical RCEs in Skype for Business, MSMQ and RRAS.

A few vulnerabilities worth mentioning:

Windows Update Stack Elevation of Privilege Vulnerability (CVE-2026-81963)
Microsoft reports that CVE-2026-81963 is being exploited, though it was not publicly disclosed before Patch Tuesday. This Important-severity Windows Update Stack elevation of privilege vulnerability has a CVSS score of 7.8 and affects Windows 11 and Windows Server 2025 systems. The flaw involves improper link resolution before file access, allowing a local, authenticated attacker with low privileges to abuse link-following behavior and elevate to SYSTEM privileges. Administrators should prioritize applying the Windows security updates for affected Windows 11 and Windows Server 2025 systems, including Server Core installations.

Windows Advanced Local Procedure Call (ALPC) Elevation of Privilege Vulnerability (CVE-2026-85880)
Microsoft lists CVE-2026-85880 as exploited in the wild, although it was not publicly disclosed before Patch Tuesday and is not currently in CISA’s Known Exploited Vulnerabilities catalogue. This Important-severity Windows ALPC elevation of privilege vulnerability has a CVSS score of 7.8 and affects Windows 10 and multiple Windows Server releases, including Server 2012, 2016, 2019, and 2022. The flaw is a heap-based buffer overflow that can be exploited locally by an attacker who can run code in a low-privilege AppContainer; no user interaction is required. Successful exploitation allows the attacker to escape the sandbox and gain SYSTEM privileges on the affected host. Given Microsoft’s exploited-in-the-wild assessment, prioritize deployment of the applicable Windows security updates, especially on multi-user systems, exposed workstations, and servers where local code execution paths are available.

Skype for Business Remote Code Execution Vulnerability (CVE-2026-66302)
Microsoft reports that CVE-2026-66302 is not being exploited in the wild and was not publicly disclosed before Patch Tuesday. This is a Critical remote code execution vulnerability in Skype for Business Server with a CVSS score of 9.8, affecting Skype for Business Server 2015 CU13, Skype for Business Server 2019 CU8, and Skype for Business Server Subscription Edition CU1. The flaw involves external control of a file name or path, allowing an unauthenticated attacker to send a specially crafted network request that writes an attacker-controlled file to an arbitrary location on the affected server; successful exploitation could allow code execution on the target server without authentication or user interaction. Administrators should prioritize applying Microsoft’s updates for affected Skype for Business Server installations and review exposed deployments, logging, and access controls for signs of suspicious file writes or unexpected server-side code execution.

Windows Message Queuing Remote Code Execution Vulnerability (CVE-2026-69579)
Microsoft reports that CVE-2026-69579 is not known to be exploited in the wild and was not publicly disclosed before Patch Tuesday. This Critical remote code execution vulnerability carries a CVSS score of 9.8 and is a use-after-free flaw in Windows Message Queuing affecting supported Windows client and server releases. An unauthenticated attacker could exploit it remotely by sending a specially crafted packet to an affected Message Queuing service, with no user interaction required, potentially allowing code execution on the target system with high impact to confidentiality, integrity, and availability. Systems running MSMQ should be prioritized for patching; where Message Queuing is not needed, disabling the service or restricting network access to it, including limiting exposure of MSMQ traffic such as TCP port 1801, can reduce risk until updates are applied.

Windows Routing and Remote Access Service (RRAS) Remote Code Execution Vulnerability (CVE-2026-69590)
CVE-2026-69590 is not listed by Microsoft as exploited in the wild and has not been publicly disclosed; it is a Critical remote code execution vulnerability in Windows RRAS with a CVSS score of 9.8. An unauthenticated remote attacker could exploit the flaw by sending a specially crafted packet to an affected RRAS service over the network, with no user interaction required, potentially allowing code execution on the target system with serious confidentiality, integrity, and availability impact. Affected platforms include supported Windows 10, Windows 11, and Windows Server releases. Organizations should apply the Microsoft security update promptly, especially on systems running RRAS, and reduce exposure by disabling RRAS where it is not needed, restricting network access to the service with firewalls or VPN controls, and monitoring for unexpected traffic to RRAS-enabled hosts.

This was a summary of Microsoft’s monthly updates highlighting key vulnerabilities. Prioritize the exploited Important Windows EOP flaws, CVE-2026-81963 and CVE-2026-85880, then patch exposed Skype for Business, MSMQ, and RRAS systems vulnerable to Critical unauthenticated RCE.

A detailed list of this month's vulnerabilities follows below. To search and filter them, visit my dashboard: https://patchlens.io