MatheuZ
Red Team Operator, Offensive Security Researcher, and Pentester
Linux-focused offensive security research: evasion, rootkits, telemetry bypass, and post-exploitation write-ups.
Writing
- 2026-07-06 · 9 minBPF Map Poisoning: Attacking the EDR from the Inside
Standard EDR evasion is avoidance. Anonymous mmap instead of a file, direct syscalls to skip libc hooks, memfd_create so fanotify never sees a path. Stay out of what the EDR is watching. BPF Map Poisoning does the opposite: walk into the EDR and rewrite its monitoring state directly. I use Falco as the demo target because it’s open-source and easy to reproduce in a lab. But the issue is architectural: CrowdStrike Falcon on Linux, Elastic Defend, Tetragon, any tool that keeps monitoring state in BPF maps without security_bpf_map enforcement is in the same position. The demo is Falco; the problem is not.
- 2026-06-03 · 24 minTrend Micro Deep Security Agent Research: Forcing bmhook/tmhook Reloads to Open a Protection Bypass Window
Research scope: This is security research on Trend Micro Deep Security Agent on Linux. The finding is not remote code execution and it is not a persistent kill switch. It is a forced security-control gap. A local unprivileged event storm can make the agent unload and reload its own behavior-monitoring kernel modules. During that window, protection behavior changes, and an artifact that was normally blocked was written to disk successfully.
- 2026-02-09 · 16 minBreaking eBPF Security: How Kernel Rootkits Blind Observability Tools
Stealthy Kernel Rootkit: https://github.com/MatheuZSecurity/Singularity Rootkit Researchers: https://discord.gg/66N5ZQppU7 Me: 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.
- 2025-11-09 · 5 minIoctl Secrets Writeup
Challenge Description In this challenge, we’re given access to a Linux virtual machine (VM) running Ubuntu. The objective is to exploit a custom kernel module to retrieve a hidden flag. The challenge involves reverse engineering, kernel internals, and crafting a proper exploit. What we have: A hidden kernel module loaded at boot Character device at /dev/ioctl_dev Setup script (device.sh) that loads the module and shreds source files SSH access enabled (username: root, password: ioctl) Important Note: Many participants had difficulties copy-pasting code directly into the VM console. As stated in the challenge description, SSH is enabled for easier interaction! This was a common pain point, so let’s start by addressing it.
- 2025-10-30 · 20 minEvading Elastic Security: Linux Rootkit Detection Bypass
Stealthy Kernel Rootkit: https://github.com/MatheuZSecurity/Singularity Rootkit Researchers: https://discord.gg/66N5ZQppU7 Introduction Security solutions continue to intensify. Modern EDRs like Elastic Security, integrated with Elastic Defend, employ multiple detection layers including YARA signatures and behavioral analysis to identify Linux kernel rootkits, triggering 26+ alerts on a single malicious module. This article demonstrates how to systematically evade these defenses. We present a comprehensive case study of developing a Linux rootkit that successfully bypasses Elastic Security’s detection mechanisms through obfuscation, fragmentation, and staged execution techniques. All content is strictly for educational purposes only.