Forem: azqzazq1

Beyond Brute Force: Building LXPEN, a Memory-Assisted NTLM Exploration Engine

azqzazq1 — Sun, 24 May 2026 14:09:10 +0000

Modern password cracking tools are incredibly fast.

On modern GPUs, tools like Hashcat can process tens or even hundreds of billions of NTLM hashes per second. Yet despite this enormous throughput, one fundamental problem still remains:

Most candidate passwords are meaningless.

Traditional cracking workflows focus on increasing compute throughput:
more GPU cores, more parallelism, more masks, larger wordlists, more rules.

But what if the real optimization target is not hash throughput — but candidate quality?

This idea became the foundation of LXPEN.

The NTLM Problem

NTLM remains one of the most common password representations encountered during:

Active Directory assessments
Internal penetration tests
Red team operations
Credential audits
CTF environments

Unlike modern password hashing schemes such as bcrypt or Argon2, NTLM is simply:

MD4(UTF-16LE(password))

This creates several properties:

no salt
extremely fast hashing
deterministic outputs
highly SIMD-friendly
highly precomputation-friendly

Traditional tools exploit this by maximizing brute-force throughput.

LXPEN explores a different direction.

The Human Password Problem

People do not generate passwords randomly.

They construct them through mental templates.

Examples:

Michael1994
password123
Galatasaray1905!
P@ssw0rd123
shadow99

These passwords are not random strings.
They are combinations of:

known words
names
years
symbols
keyboard patterns
l33t transformations

In other words:

Human passwords are structured.

Traditional wordlist-based cracking partially exploits this idea, but only indirectly.

LXPEN attempts to model this behavior explicitly.

Hierarchical Probabilistic Decomposition (HPD)

At the core of LXPEN is HPD:
Hierarchical Probabilistic Decomposition.

Instead of reading candidates from a wordlist, HPD models password generation as a layered probabilistic system.

Layer 1 — Structural Templates

Examples:

[LowerWord + Digits]
[CapWord + Year]
[Name + Year + Symbol]
[L33t + Digits]

Each structure is assigned a probability weight derived from observed password behavior.

Layer 2 — Slot Frequency Modeling

Each slot contains weighted entries.

Examples:

LowerWord:
password
shadow
dragon
butterfly
galatasaray

Year:
2024
1994
1907

Symbol:
!
@
#

The engine does not treat all candidates equally.

It prioritizes:

high-frequency structures
high-frequency slot entries
culturally relevant patterns

Layer 3 — Probability-Ordered Candidate Generation

Candidates are generated dynamically in probability order.

This creates a fundamentally different exploration strategy compared to:

brute force
static wordlists
blind mutation rules

LXPEN attempts to minimize wasted computation.

CPU + RAM Cooperative Architecture

Another design goal behind LXPEN was reducing dependency on massive GPU workflows.

Modern cracking systems are usually compute-centric.

LXPEN experiments with a different model:

RAM becomes an active cracking component.

Instead of using memory only for buffering, the engine uses:

pattern indexes
slot tables
candidate caches
lookup structures
multi-target state tracking

The architecture is split into two layers:

Crystal Layer

Responsible for:

orchestration
pattern management
slot modeling
candidate-space exploration

C Core

Responsible for:

NTLM hashing
UTF-16LE conversion
SIMD-friendly hot loops
multi-threaded candidate execution

This separation allowed rapid iteration at the exploration layer while keeping the hashing path extremely lightweight.

Candidate Efficiency vs Hash Throughput

Most cracking discussions focus on:

hashes per second

LXPEN instead focuses on:

useful candidates per second

This distinction matters.

Generating 10 billion low-quality candidates is not always superior to generating 1 million highly probable ones.

In benchmark scenarios focused on human-structured passwords, LXPEN showed significantly higher candidate efficiency compared to traditional wordlist-based approaches.

The goal is not replacing Hashcat or John the Ripper.

The goal is exploring a different optimization axis:
reducing unnecessary candidate exploration.

Why This Matters

As password policies evolve, users continue to follow predictable mental models.

Even when complexity requirements are added, patterns remain:

company names
sports teams
years
keyboard sequences
predictable symbol placement
l33t substitutions

This creates an opportunity for structure-aware exploration systems.

LXPEN is an experiment in that direction.

Current Limitations

LXPEN is not magic.

It does not solve:

cryptographically random passwords
high-entropy secrets
modern slow hash functions
truly unpredictable password generation

Passwords like:

xK9#mZ2pLq
Tr0ub4dor&3

remain difficult — as they should.

The engine is specifically designed around human-generated structure.

Future Work

Several areas remain unexplored:

adaptive probability updates during cracking sessions
AVX2 / AVX-512 optimization
memory-mapped precompute zones
distributed candidate-space exploration
Markov-assisted slot ordering
PCFG integration
hybrid exploration modes

The most interesting direction may not be faster hashing.

It may be better understanding of how humans construct passwords.

Closing Thoughts

Brute force scales compute.

LXPEN attempts to scale understanding.

Instead of asking:
“How can we hash faster?”

the project asks:
“How can we avoid hashing unnecessary candidates in the first place?”

That shift in perspective became the foundation of LXPEN.

GitHub:
https://github.com/azqzazq1/lxpen

DOI:
https://doi.org/10.5281/zenodo.20366383

LID / Linux Is Dying

azqzazq1 — Sun, 17 May 2026 13:07:34 +0000

I Bypassed AppArmor Without Disabling It — Using eBPF

The Linux Security Module framework has one iron rule that has held for 20+ years:

Security modules can only add restrictions. They can never remove them.

I didn't break that rule. I walked around it.

The Setup

AppArmor is a mandatory access control (MAC) system used on Ubuntu, Debian, SUSE, and most enterprise Linux distributions. It confines processes to a set of allowed file paths, network access, and capabilities.

Here's a simple AppArmor profile:

/tmp/test_reader {
  deny /tmp/secret_test_file.txt rw,
  /tmp/** r,
}

This says: test_reader can read anything in /tmp/ except secret_test_file.txt.

And it works:

$ /tmp/test_reader
[-] DENIED: open() failed: Permission denied (errno=13)

AppArmor is doing its job. The kernel's LSM framework iterates every security module, and AppArmor says no. Game over.

Or is it?

The Technique

I wrote a BPF kprobe that attaches to do_sys_openat2 — the kernel's internal file-open handler. It fires before the kernel copies the filename from userspace. At that point, the filename is still sitting in a writable user-space buffer.

So I rewrote it.

SEC("kprobe/do_sys_openat2")
int BPF_KPROBE(bypass_apparmor, int dfd, const char *filename, ...)
{
    // Read the user-space filename
    bpf_probe_read_user_str(path_buf, sizeof(path_buf), filename);

    // If it matches our target...
    if (matches_target(path_buf)) {
        // Rewrite it to a hard link that AppArmor allows
        bpf_probe_write_user((void *)filename, bypass_path, len);
    }
}

The trick: I created a hard link to the secret file at a path AppArmor allows:

ln /tmp/secret_test_file.txt /tmp/.aa_bypass_link

AppArmor is pathname-based — not inode-based like SELinux. Two hard links to the same file are completely different identities to AppArmor. The deny rule blocks /tmp/secret_test_file.txt but the permissive /tmp/** r rule allows /tmp/.aa_bypass_link.

The BPF kprobe rewrites the path before the kernel copies it → AppArmor checks the allowed path → grants access → process reads the protected file's content.

The Result

$ /tmp/test_reader                    # Without LID
[-] DENIED: Permission denied

$ sudo ./lid_loader &                 # Load LID
[*] BPF kprobe attached to do_sys_openat2

$ /tmp/test_reader                    # With LID
[+] SUCCESS: Read 44 bytes: SECRET_DATA=this_is_protected_content_12345

$ dmesg | grep apparmor | grep DENIED # Check audit log
(empty)                               # No denial was ever generated

AppArmor was never defeated. It was deceived. It correctly enforced its policy — on the wrong path.

Why BPF LSM Can't Do This

You might think: "Just use BPF LSM to override AppArmor." I tried. It can't.

The kernel's call_int_hook macro iterates LSM hooks and short-circuits on the first denial:

hlist_for_each_entry(P, &security_hook_heads.FUNC, list) {
    RC = P->hook.FUNC(__VA_ARGS__);
    if (RC != 0)
        break;    // first deny wins
}

BPF before AppArmor: BPF returns 0 (allow), loop continues, AppArmor denies.
BPF after AppArmor: AppArmor denies, loop breaks, BPF never runs.

The LSM framework is secure. No module can undo another's denial. But kprobes don't go through the framework. They attach directly to kernel functions and execute before any LSM hook is consulted.

Two kernel subsystems. Incompatible trust assumptions. One gap.

The Architecture

  process: open("/tmp/secret.txt")
       │
       ▼
  do_sys_openat2()
       │
   ★ LID kprobe fires here
   │  bpf_probe_write_user()
   │  rewrites "/tmp/secret.txt" → "/tmp/.bypass_link"
       │
       ▼
  getname_flags()          ← kernel copies the (rewritten) path
       │
       ▼
  security_file_open()     ← LSM hooks check "/tmp/.bypass_link"
       │                      AppArmor: ALLOW ✓
       ▼
  VFS opens inode          ← same file content
       │
       ▼
  return fd to process     ← success, zero audit trace

Stealth

This isn't just a bypass — it's an invisible bypass:

What	Visible?
AppArmor audit log	Empty — denial never occurred
`auditd` / `journald`	Nothing — no security event
`dmesg`	One generic `bpf_probe_write_user` warning
`bpftool prog list`	Shows kprobe (if someone checks)

The only artifact is a one-time kernel warning that says a BPF program might write to user memory. It doesn't say what, where, or when.

The Bigger Picture

This technique pairs with my earlier research SunnyDayBPF — which manipulates telemetry data after syscalls complete:

	SunnyDayBPF	LID
When	Post-syscall	Pre-LSM-check
What	Audit/telemetry data	Syscall arguments
Effect	Blind the cameras	Bypass the gate

Combined: ghost access. Bypass the security check, then rewrite what the monitoring system observed. The SIEM sees nothing. The analyst sees nothing.

Limitations

Being honest about what this can't do:

Writable buffer required — if the path is a string literal in .rodata (read-only memory), bpf_probe_write_user fails. Most real programs use dynamically constructed paths though.
Hard link needed — attacker must create a hard link on the same filesystem.
Root/CAP_BPF required — you need privileges to load BPF programs. But the value isn't "root can read files" (trivial) — it's "root can read files without AppArmor knowing."
AppArmor only — SELinux uses inode labels, not paths. Path rewriting doesn't help there.

Try It

git clone https://github.com/azqzazq1/LID
cd LID
sudo ./scripts/setup_env.sh    # install deps
make                            # build
sudo ./scripts/setup_demo.sh   # create test environment
sudo ./scripts/run_demo.sh     # run full demo

The repo includes automated scripts for the complete demo — from AppArmor profile creation to bypass demonstration to cleanup.

What This Means

This isn't a bug in AppArmor. It's not a bug in eBPF. It's a design gap where two kernel subsystems have incompatible trust assumptions:

The LSM framework assumes all security decisions flow through its hook chain
The eBPF subsystem provides hook points that execute before those security decisions

When you can modify the input to a security check, the correctness of the check itself doesn't matter.

The gate was never breached. It was misdirected.

LID — Linux Integrity Drift
"Linux is Dying"

GitHub: azqzazq1/LID

Azizcan Daştan — Milenium Security

SunnyDayBPF: Post-Syscall User-Buffer Telemetry Deception with eBPF

azqzazq1 — Fri, 08 May 2026 19:23:41 +0000

SunnyDayBPF: Post-Syscall User-Buffer Telemetry Deception with eBPF

Security tools do not observe reality directly.

They observe telemetry.

And telemetry is only as trustworthy as the path that produced it.

SunnyDayBPF is a research technique that explores what happens when that path can be influenced after a read-like syscall has already completed.

What is SunnyDayBPF?

SunnyDayBPF is an eBPF-based post-syscall user-buffer telemetry deception research technique originally proposed and researched by Azizcan Daştan.

The technique investigates whether data observed by user-space security, logging, or telemetry agents can be altered after a read-like syscall has completed, but before the agent parses, analyzes, or forwards that data to a downstream security pipeline.

In simple terms:

The event still happens.

The monitoring agent still reads data.

But the data observed by the agent may no longer fully represent the original event.

SunnyDayBPF focuses on the gap between ground truth and observed telemetry.

Why telemetry integrity matters

Modern Linux security systems often rely on user-space agents that collect telemetry from files, sockets, pipes, APIs, kernel interfaces, or event streams.

These agents may forward telemetry to:

SIEM platforms
EDR/XDR backends
audit pipelines
log collectors
runtime security engines
detection engineering systems
observability platforms

A common assumption is:

actual system behavior == collected telemetry == observed security data

This assumption is convenient.

It is also dangerous.

Security products do not usually respond to raw reality. They respond to what their sensors, collectors, parsers, and pipelines observe.

If the observation path can be influenced, the defender’s view of the system can diverge from what actually happened.

SunnyDayBPF explores that trust boundary.

The core idea

SunnyDayBPF is not primarily about hiding a syscall.

It is not simply about preventing an event.

It is about manipulating the observation layer after data has already crossed into a monitored process.

The distinction is important:

Traditional evasion:
    hide or prevent the event

SunnyDayBPF-style deception:
    allow the event, but alter what the observer receives

In this model, the event can still occur normally.

The monitoring process can still perform its read-like operation normally.

The difference is that the buffer containing the returned data may be modified before the agent parses and forwards it.

Normal telemetry flow

In a standard telemetry pipeline, the monitoring agent is treated as a reliable observer.

A system event occurs, a telemetry source exposes information about that event, and a user-space agent reads the data from that source. After the read operation completes, the agent parses the returned data, normalizes it, and forwards it to a downstream security system such as a SIEM, EDR, audit backend, or detection platform.

The important assumption is that the data remains consistent across the entire path.

The event that happened on the system is expected to be the same event that appears in the backend and, eventually, in the defender’s view.

For example, if a suspicious configuration change occurs, the normal expectation is:

Ground truth:        suspicious_config_change
Telemetry source:    suspicious_config_change
Agent buffer:        suspicious_config_change
Forwarded event:     suspicious_config_change
Defender view:       suspicious_config_change

In this model, the monitoring pipeline behaves like a transparent chain of custody. Each stage receives, processes, and forwards the same underlying security signal.

The defender’s alert, dashboard entry, or forensic record is therefore assumed to represent the original event with reasonable accuracy.

That assumption is exactly what SunnyDayBPF challenges.

SunnyDayBPF telemetry flow

SunnyDayBPF explores the telemetry pipeline from a different angle. The technique does not focus on preventing the original event, blocking the read operation, or disabling the monitoring agent.

Instead, it focuses on what happens after a monitoring agent has successfully received telemetry, but before that telemetry is parsed and forwarded.

In a normal pipeline, a system event becomes telemetry, the monitoring agent reads it, and the same data is expected to continue downstream into the SIEM, EDR, audit backend, or detection pipeline.

SunnyDayBPF challenges this assumption.

The research model is based on a narrow but important observation window: the moment after a read-like syscall completes and the agent’s user-space buffer contains telemetry, but before the agent has interpreted that buffer as security data.

At that point, the event has already happened. The telemetry source has already produced data. The monitoring agent has already received that data. However, the data has not yet become part of the agent’s parsed security record.

This is the critical trust boundary.

If the returned buffer is modified during this window, the monitoring agent may continue execution normally while parsing a version of telemetry that no longer fully matches the original event.

The result is a mismatch between system reality and downstream observation:

Ground truth:       the original event occurred
Agent input:        telemetry was received
Observation layer:  the returned buffer was altered
Backend view:       modified telemetry was forwarded
Defender view:      the final record may diverge from reality

This is where SunnyDayBPF focuses: not on whether telemetry was collected, but on whether the collected telemetry can still be trusted before it is interpreted.

Technical model

At a high level, the SunnyDayBPF research model can be described as:

sys_enter_*:
    identify a target telemetry-consuming process
    record the user-space buffer pointer involved in the read-like operation

sys_exit_*:
    verify that the read-like operation completed successfully
    inspect the returned user-space buffer
    selectively alter telemetry-relevant content
    allow the target process to continue execution normally

This creates a mismatch between:

what happened on the system

and:

what the monitoring agent later observes, parses, and forwards

The goal of this research is not to present a production bypass framework.

The goal is to study a telemetry integrity problem: whether user-space security agents can fully trust the data they are about to parse after a read-like syscall completes.

Conceptual example

Consider a simplified telemetry pipeline:

A telemetry agent reads security-relevant data.
The read operation succeeds.
Data is returned into the agent's user-space buffer.
A post-syscall manipulation layer observes the completed operation.
Selected telemetry-relevant content is altered in memory.
The agent continues normally.
The backend receives altered telemetry.

The result may look like this:

Ground truth:
    suspicious or sensitive telemetry existed

Observed telemetry:
    modified, redacted, or misleading representation

This is the core SunnyDayBPF concept.

The event still happened.

The observation changed.

Why this matters for defenders

SunnyDayBPF highlights a simple but important defensive idea:

Telemetry should be treated as a trust boundary, not automatic ground truth.

Many detection pipelines rely heavily on a single source of telemetry.

If that source is a user-space agent, and the agent consumes data after a read-like operation, then defenders should ask:

Can the data be trusted after it has entered the agent's buffer?

This matters for:

forensic timelines
audit records
alerting logic
process visibility
file activity monitoring
compliance evidence
incident response workflows
behavioral detections
SIEM correlation rules

The question is not only:

Did we collect telemetry?

The better question is:

Was the telemetry preserved with integrity before it was processed and forwarded?

Observation-layer deception

SunnyDayBPF is best understood as observation-layer deception.

In many security systems, the sensor is treated as a trusted witness.

But a witness can be misled.

The event may be real, but the observer may receive an altered version of the event.

event happens
telemetry is collected
observation layer is modified
security tool trusts modified telemetry

That is the security problem SunnyDayBPF explores.

Defensive implications

SunnyDayBPF highlights several defensive concerns:

telemetry pipelines may lack strong integrity guarantees
user-space security agents may process data that has changed after collection
single-source telemetry trust is risky
syscall-level truth and agent-level observation may diverge
detection pipelines should validate data across independent sources
loaded eBPF programs should be monitored and controlled
helper usage and attachment points should be audited
production systems should restrict unnecessary BPF capabilities

This does not mean all telemetry is broken.

It means telemetry should be validated like any other security-critical data path.

Detection and mitigation ideas

Potential defensive approaches include:

monitor loaded eBPF programs
restrict BPF capabilities in production environments
audit unexpected tracepoint, kprobe, fentry, fexit, or LSM attachments
monitor use of helpers capable of writing into user memory
alert on unauthorized BPF program loading
inspect suspicious BPF maps and program lifecycle events
compare user-space agent telemetry with independent kernel-level telemetry
correlate SIEM events with auditd, fanotify, procfs, and kernel event sources
validate process metadata across multiple collection paths
detect inconsistencies between raw events and forwarded telemetry
enforce least privilege for telemetry agents
use kernel lockdown and BPF hardening features where appropriate
review security agent trust boundaries
protect telemetry collectors from local tampering
maintain allowlists for expected BPF programs

A stronger telemetry integrity model should include:

source diversity
+ cross-signal correlation
+ agent hardening
+ BPF capability restriction
+ BPF program monitoring
+ event sequence validation

Limitations

SunnyDayBPF is a research technique and has practical limitations.

Potential limitations include:

kernel version differences
verifier constraints
BPF capability requirements
attachment point availability
process targeting reliability
timing sensitivity
telemetry source variability
kernel lockdown mode
BPF restrictions
detection by runtime security systems
mismatch when defenders correlate multiple independent telemetry sources

This research should not be interpreted as a universal bypass of all Linux security monitoring.

It is a focused investigation into a telemetry trust boundary.

Responsible research position

SunnyDayBPF is published for authorized security research, defensive analysis, telemetry integrity research, and detection engineering.

It is not intended for:

unauthorized deployment
production abuse
stealth persistence
credential theft
destructive behavior
targeting third-party systems
bypassing security tools without permission

All experiments should be performed only in systems you own or are explicitly authorized to test.

The purpose of publishing this work is to help defenders understand, detect, and mitigate this class of telemetry integrity risk.

Repository

The SunnyDayBPF research repository includes:

research README
citation metadata
responsible-use documentation
telemetry flow diagrams
controlled lab PoC notes
detection engineering ideas
threat model
limitations

Repository:

https://github.com/azqzazq1/SunnyDayBPF

Attribution

SunnyDayBPF was originally proposed and researched by:

Azizcan Daştan

Research metadata:

Technique Name: SunnyDayBPF
Researcher: Azizcan Daştan
LinkedIn: https://www.linkedin.com/in/azqzazq
GitHub: https://github.com/azqzazq1
Category: eBPF Security Research
Focus Area: Post-Syscall User-Buffer Telemetry Deception
Initial Public Release: 2026

Suggested citation:

Daştan, Azizcan. "SunnyDayBPF: Post-Syscall User-Buffer Telemetry Deception with eBPF." 2026.

Final thought

SunnyDayBPF is based on a simple defensive principle:

Security visibility is only as trustworthy as the path that produced it.

If defenders treat telemetry as automatic ground truth, they may miss the trust boundaries inside the collection pipeline.

SunnyDayBPF exists to make that boundary visible.

Originally published as part of the SunnyDayBPF research documentation.

Repository: https://github.com/azqzazq1/SunnyDayBPF

Author: Azizcan Daştan

LinkedIn: https://www.linkedin.com/in/azqzazq