Report below on Ubiquiti compromise tactics and indicators. Includes OpenSSH backdoor/credential harvesting and dropped SSH key. Plus custom python based backdoors, iptables proxying and tampered binaries. Some thoughts.

ic3.gov/Media/News/202…
Using SSH with passwords means a trojanized binary will steal any credential of someone logging in. If you are not using public keys with SSH on Ubiquti and other devices (which prevents this), at least use a unique password with *each* device. Do not re-use passwords.

Thanks to one of my anonymous spies, I have run this Linux backdoor and @SandflySecurity easily found it. As discussed:

Process masquerading (renames itself [syslogd])
Opens raw UDP socket for comms
Impersonates kernel thread
Waits for instructions

More details in thread...

https://twitter.com/haxrob/status/1762821513680732222

As disclosed, it runs as [syslogd] after exec. This is easily seen with a ps -auxwf command that it is sitting out all alone and not part of the main [kthreadd] process PID 2.

ps -auxwf is your friend.

The translated Ukrainian report contains more details on these attacks. Let's go over them in this thread. @SandflySecurity can find many of these tactics out of the box right now.

https://twitter.com/BleepinComputer/status/1713979860404576348

Backdoor PAM authentication and grab passwords used to login. The stolen passwords are dropped in this file with simple XOR encryption:

/lib/libc.so.7

I don't like seeing weird files under /lib directories. Here we flag a standard ELF trying to hide as a shared object variant.

This is a great write-up from @Mandiant about a Fortinet attack and evasive backdoor. The backdoor uses port knocking and IP tables forwarding reminiscent of the BPFDoor malware we wrote about last year.

mandiant.com/resources/blog… FYI, agentless @SandflySecurity can run on many embedded and IoT devices instantly where other EDRs can't. We do this today and you can use our free license to check your systems.

"Sandfly is where agents can't be."

sandflysecurity.com/get-sandfly/

I asked ChatGPT to analyze a suspicious Linux process masquerading as the "date" command. However I had it do so in the style of WOPR from WarGames. It provided an excellent analysis based on the raw data from @SandflySecurity along with some guidance. Thread... The "date" command was flagged on a Linux host. I removed the explanation why it was detected so we could see what ChatGPT could make of it as a forensic analyst without any help. The initial observations are an excellent starting point for a Linux investigation:

Let's have ChatGPT give an opinion on a masquerading Linux process that was detected hiding on a system. I'll feed it the JSON with no other hints other than the data @SandflySecurity provided. ChatGPT summarizes the data, and even pulls out that the process deleted flag is set to true so it's masquerading and also deleted itself to hide.

ChatGPT helping investigate a suspicious Linux kernel module suspected of being a rootkit. I ask it to parse the JSON and it identifies the key fields. I ask it whether this kernel module called "Diamorphine" that was found is suspicious. The answer is concise and correct. It's cribbing our explanation a little, but still augmented with other data so we'll let it go.

I have been using #ChatGPT to help with Linux forensic investigations. It is an incredibly useful tool when guided with a little knowledge. In this thread I'm going to demonstrate how to investigate a suspicious process with SCTP sockets operating using @SandflySecurity First we'll paste in the raw event JSON and ask it to interpret it. ChatGPT does a great job understanding the fields without any prompting. It knows a security tool generated it and identifies key fields rapidly.

I have been using #ChatGPT to help with Linux forensic investigations. It is an incredibly useful tool when guided with a little knowledge. In this thread I'm going to demonstrate how to investigate a suspicious process with SCTP sockets operating using @SandflySecurity First we'll paste in the raw event JSON and ask it to interpret it. ChatGPT does a great job understanding the fields without any prompting. It knows a security tool generated it and identifies key fields rapidly.

Sandfly users (even free users) can enable the following incident response checks to flag processes running as sniffers. It will easily find #BPFdoor. Here's how in this thread: We have checks for sniffer activity in the incident response modules. They are not run by default as they can be noisy at times, but we do have a tuned version that is not noisy. Select the hosts you want scanned, then in sandfly selection use the filter to find "sniffer".

I looked at the sources for #BPFdoor and ran @SandflySecurity against the binary. We could find this since at least 1.x of our product. Here is a run down of what it is doing.

https://twitter.com/GossiTheDog/status/1522964028284411907

#BPFdoor uses eBPF to sniff traffic. It can bypass firewall rules to see packets. When it starts it writes to /var/run/haldrund.pid which is obfuscated as hex in the code. It also masquerades its name using a number of pre-defined command line values below:

People are asking me to post hashes about this Linux malware we came across. No. Using hashes for finding Linux malware doesn't work and are easily altered. Look for tactics instead. Here are some tactics to use in this thread.

https://twitter.com/CraigHRowland/status/1422009387686645761

Can you see the /etc/ld.so.preload file? Can you read it with /bin/cat or see it with the /bin/ls command? If you are being stopped from doing this then you have ld preload malware stopping you.

More on this Linux stealth malware below.

https://twitter.com/CraigHRowland/status/1421981128584351746

Modified /etc/ld.so.preload to point to a malicious library to intercept system calls. The file was /lib/libcurl.so.2.17.0 and was not known by VirusTotal. The /etc/ld.so.preload file contents was being hidden from system commands. It was marked immutable to make removal harder.

You see a weird openssl command running on one of your Linux systems. Here's how to investigate whether it's a bindshell backdoor operating on the box and hiding traffic inside an encrypted tunnel. Thread. #DFIR The server and client to run the attack. The reverse bindshell causes openssl to connect back to us and is encrypted so network monitoring is blind to what is going on. Need to look at the host to figure it out.

@SandflySecurity was able to spot this malware very quickly and with multiple serious alerts. Let's have a walk-through about what it was up to and de-cloak it. #DFIR #sandflysecurity

https://twitter.com/vanjasvajcer/status/1333805446302461953

Virus total shows very few results. But we saw many serious compromise tactics in use on this Linux system hit with the malware.

You can find #Linux malware masquerading as a kernel thread using this command:

cat /proc/<PID>/maps

I'm going to show you how in this thread.

#DFIR #sandflysecurity Malware will name itself with [brackets] to impersonate a Linux kernel thread. Bracketed names mean no cmd line argument. Kernel threads almost always are in brackets.

Use ps with tree view to find our candidates for investigation:

ps auxwf | grep "\["

#DFIR #sandflysecurity

Let's go step-by-step and do some basic live process forensics for #Linux. Today's contestant is a bindshell backdoor waiting for a connection on Ubuntu. We saw something odd when we ran:

netstat -nalp

#DFIR #threathunting #forensics netstat -nalp shows a process named "x7" PID with a listening port that we don't recognize. #DFIR

Here's how to recover a #Linux binary from a malicious process that has deleted itself from the disk.

cp /proc/<PID>/exe /tmp/recovered_bin

Let's see how this works. #DFIR #threathunting #forensics Often, malware deletes itself after it starts so file scanners and integrity checks won't find it. It can make analysis harder if you can't get to the binary easily.

But if you remember /proc/<PID>/exe you can recover any deleted binary.

#DFIR #threathunting #forensics