Proxy Bar

CVE-2026-1357 WPvivid Backup & Migration
*
writeUP + RCE PoC

CVE-2026-20841 - Windows notepad.exe RCE
*
PoC

Burp MCP + Codex CLI
*
how to connect - manual

CVE-2026-25639 Axios
*
Trigger DoS and Crash Node.js Servers.
*
PoC

CVE-2026-1731 BeyondTrust Remote Support
*
Pre-Auth RCE PoC exploit

Building a CobaltStrike AggressorScript Bridge for Any Language
*
Link + agscript_middleware

Рубрика На заметку $USERNAME@hacker.wtf - part 4
*
ptrace + удалённый ELF = живое и моргает

Как я уже писал выше если ELF уже подгружен в память (через execve, memfd, mmap) — удаление файла ничего не меняет, бинаря нет, inode удалён. За то ptrace позволяет подрубиться к такому процессу и управлять его памятью / регистрами.
В итоге безфайловый процесс живёт как паразит, код которого можно модифицировать / расширять на лету.
как это выглядит:

./evil &                #процесс стартует как обычно
rm evil                 #удаляем, inode остаётся в памяти, код уже mmap’нут
ls -l /proc/<pid>/exe   #чекаем, увидим что то вроде # -> evil (deleted)

ну а дальше через ptrace (и да, обычно от rootины)

PTRACE_ATTACH

тут процесс тормозится и ядро разрешает нам: читать память, писать в память, менять регистры, рулить потоками исполнения.
ptrace нужен только PID.
В /proc/<pid>/maps можно почитать код удалённого ELF, увидеть адреса сегментов, r-xp области, дампить, модифицировать и тд.
А еще можно ЗАИНЖЕКТИТЬ НОВЫЙ КОД ! Для этого надо: куриный кубик магги найти свободную память
(ну или вызвать mmap внутри процесса), залить payload в эту область, посохранять старые регистры, изменить RIP > на payload, вернуть управление обратно.
Fileless persistence они такие.
Кстати отлично комбинируется с LD_PRELOAD
А вот тут можно спалиться:

cat /proc/sys/kernel/yama/ptrace_scope

В мире *nix имя файла — это вообще иллюзия. Реальность — это память, так то.

#РубрикаНаЗаметкуХакеру

WoW
*
so fucking cool

#1995 #mainframe #hackers

Рубрика На заметку $USERNAME@hacker.wtf - part 3
*
Zombie FD - файл закрыт, но mmap то жив !

fd = open("secret", O_RDONLY);
ptr = mmap(fd);
close(fd);
unlink("secret");

Файла нет, FD закрыт, lsof ничего не покажет, но данные всё ещё доступны. Тут только /proc/<pid>/maps руками смотреть, людям из форензики плохеет.
*
*
process_vm_readv - читаем невидимое.
Смоделируем сценарий - файл удален, fd закрыт и даже mmap’нут, НО ПРОЦЕСС пока ЖИВ.
process_vm_readv(pid, ...)
Тогда другим процессом (ну с правами) можно вытащить payload, ключи, shellcode etc.
Ну или наоборот — заинжектить данные без файлов

#РубрикаНаЗаметкуХакеру

CVE-2026-21509 exploits - MS Office
*
How to detect

Linux CentOS 9 - LPE
*
WriteUP and EXPLOIT

From Automation to Infection (Part II):
*
Reverse Shells, Semantic Worms, and Cognitive Rootkits in OpenClaw Skills

На заметку $USERNAME@hacker.wtf - part 2
*
payload + unlink = stealth mode
payload не ищется, антивирусу нечего сканировать, а процесс живёт !

payload + unlink = stealth mode
fd = open("/tmp/.x", O_CREAT|O_RDWR);
unlink("/tmp/.x");
execve("/proc/self/fd/3", ...);

*
*
mmap + unlink = призрачные данные
Пока процесс жив - данные доступны (вместе с shellcode) и даже дамп памяти их покажет, но диск чист

fd = open("secret", O_RDWR);
mmap(...)
unlink("secret");

#РубрикаНаЗаметкуХакеру

Удобно, кто то же заморочился 😎
*
jmail
*
Drive
*
Video Foto
*
Seyahatler

Ну а вдруг )
*
search

На заметку $USERNAME@hacker.wtf
*
В Linux удаление файла приводит лишь к удалению его имени из файловой системы. Если какой-либо процесс всё ещё юзает этот файл, данные остаются в памяти пока не кильнуть сам процесс.
И Linux сохраняет доступ к содержимому УДАЛЕННОГО ИСПОЛНЯЕМОГО файла до тех пор, пока он "открыт процессом".
На скринах видно запущенный процесс update-check, файл notes.txt удален из каталога, казалось бы - все круто и файл исчез. (нет)
lsof показывает, что процесс все еще держит удаленный файл открытым, а /proc/<pid> Параметр /fd подтверждает это, видим активный дескриптор файла, указывающего на него.

Помни $USERNAME, доказуха еще висит в памяти - и она очень даже доступна.

#РубрикаНаЗаметкуХакеру