A friend asked me to find out why his connected lightbulb app was asking for his location, so I ducked out to Australia’s favourite hardware store, Bunnings, and grabbed one to check out. The Android grid connect app has 500k+ downloads. Let’s take a quick look! 🧵 .(1/n)

Full writeup including mitigations, threat hunting and other detection ideas.👇.(7/7).

This method can be utilized to perform process masquerading. Here an implant appears to be running from /usr/sbin/auditd but it's actually 'fileless'. No '(deleted)', no ':memfd', no '/dev/shm', no ptrace, no LD_PRELOAD. Just stealth. (6/7)

Malware can use the unshare() or clone() syscalls to create the new mount and user namespaces. The uid/grp mapping is done by writing to procfs followed by mount(). If the process enters a spin lock, it can be used to keep a persistent hold of the 'stash space'. (5/7)

Create a new mount and user namespace, mapping the unprivileged uid to uid 0. Here the root user logs in [4] and can't see the file created by the unprivileged user in the /root directory .(4/7)

As a bonus, commands in this shell will not be written to the history file as we mounted over the user's home directory. No need to set HISTFILE=/dev/null. Once the shell exits, artifacts evaporate. Nothing touches the disk. Now how to do this as an unprivileged user? (3/7).

Let's start with the most simple example. Select a mount namespace that is not used by systemd/init. Migrate the current shell into that process's mount namespace and mount a tmpfs file system. Anything that writes the mounted path is concealed from users on the host. (2/7)

A relatively unknown but particularly stealthy technique to hide files on Linux hosts. On unhardened boxes, unprivileged users can conceal files from even the root user. Disk content remains in memory, hindering disk acquisition during forensic investigation. (1/7) 👇.

Forget compliance by severity color, how about compliance by emoji happiness level? . #systemd, stay classy. 🙃

RT @alexjplaskett: Security researcher @haxrob released a two-part technical breakdown of BPFDoor, a Linux-targeting malware tied to past A….

RT @hkashfi: Great blog posts and updates on latest BPFDoor changes by @haxrob . BPFDoor - Part 1 - The past:. BPFD….

A writeup of this content can be found in a two part series:. (22/x).

Newer samples can be found to have the authentication password as a salted MD5 hash. can extract the hashes from samples and generate the respective hashcat command. Here are a few cracked ones. Those that identify victims are not included. (21/x)

An approximate timeline of events related to #BPFDoor which spans across almost two decades:. (20/x)

There is a particular byte sequence used here that might have some meaning. The hex encoded bytes can be copied from the blog entry linked below if others would like to have a go at this piece of the puzzle. (19/20)

Another interesting feature is the ability to configure the masqueraded process name and implant password. Rather then depend on an external config file, it modifies itself. (18/20)

Unlike the familiar BPFDoor, it has a persistence mechanism built in - specify 'x' as an argument and it modifies the system wide bash profile for all users. (17/20)

BPFDoor would write a file to /var/run as a mutex lock (to prevent multiple instances. NotBPFDoor uses a semaphore by calling semget. The semaphore key is an epoch timestamp - Friday, June 5, 2015. Interesting. (16/20)

It's 'NotBPFDoor' because it does not use BPF filters. When looking for magic packets, the user space process receives all TCP traffic. An early revision of BPFDoor? . (15/20)

So what does this really tell us? Perhaps BPFDoor in some form or another has been around for quite some time and may give proximity to a particular intrusion set. Next we have what I'll call "NotBPF" with the first submitter from HK in 2016. Let's look into it. (14/20)

The sniffdoor notes reveal future ambitions that made it's way into BPFDoor. (13/20)