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.
We log into the host after seeing the weird outbound connection and need to investigate. Run ps -aux and lsof -p <PID> to see the process. Throw in netstat for good measure. We see openssl and /bin/sh -i running that look strange.
Once we see it's a PID of interest on Linux, we will go to /proc/<PID> to look around. Here we see the links to the executable and other data.
The process looks like standard openssl, so we'll now look at /proc/<PID>/cmdline and /proc/<PID>/environ to glean anything useful. These areas often leak important Linux attack information. #DFIR
We know this looks strange and has open network sockets. Let's look at the Linux maps to make sure it's not referencing any weird libraries inside /proc/<PID>/maps
So nothing is hiding that is obvious. Let's see what file descriptors it has open on Linux. This will show hidden data files, sockets, etc. the process has open that is of interest to us. *Let the process tell you what is interesting.* No need to break out the debugger. #DFIR
Right, we have a file of interest under /tmp/s. Let's look and see what it is. Appears to be a pipe with a single character name which is odd.
Doing the above steps to the /bin/sh -i process also. We see it has same links to open files so yes it's talking to openssl. They are clearly linked and referencing same Linux socket inode. They are talking to each other.
At this point we know this openssl client was not from a developer debugging a SSL certificate. It's malicious and time to initiate incident response procedures. Of course I think it's easier to use Sandfly to find this stuff automatically. #sandflysecurity #DFIR
Investigating a Linux host for backdoors manually is fun, but it's better to do it automatically. We have a free license to use our agentless Linux security platform. You can get it here instantly and use it for free on five or fewer hosts. #DFIR

sandflysecurity.com/pricing/
Full article about how to use command line Linux forensics to investigate a suspicious openssl backdoor is here with more details than I can fit in a bunch of tweets:

#DFIR #infosec

sandflysecurity.com/blog/detecting…

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Craig Rowland - Agentless Linux Security

Craig Rowland - Agentless Linux Security Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @CraigHRowland

Aug 14
@Phrack had a great article on leaked North Korean APT operations, including a Linux stealth rootkit with backdoor. I took a look at this backdoor and and wanted to share detection tips. Full article at the end of this thread. Image
Image
First, this rootkit is based on the khook library. This is a common rootkit base that allows full stealth for processes, network connections, files, etc. This is what @SandflySecurity sees when the rootkit is active. It's only stealthy if you aren't looking! Image
Like many LKM rootkits, it will be extremely fragile and needs to be built for the victim kernel version. When installed the first thing it does is drop persistence files and insert the module to hide them and itself. Here are some files in /etc and /lib it hides. Image
Image
Read 19 tweets
Aug 9
Since I apparently have so many safe fans, let's talk about my favorite safe type: Mosler Round Doors. They are absolute tanks with interesting features. Image
Image
Mosler made excellent vaults and safes of superior security and design. The round doors are my favorite as they are the absolute strongest design. The door rotates and locks into lugs when you turn the T handle. The bolts just keep the door from spinning unlocked. Image
Here we see the open door. The strength comes from the lugs. The door lugs you see here close into the frame. When you spin the handle the entire door rotates and the door lug slips in behind the frame lugs. Image
Read 11 tweets
Aug 9
I recommend placing a 24/7 monitored smoke alarm above your safe. Cutting tools make a lot of smoke and this would set off the alarm and get help dispatched while scaring off attackers. Here is a thread of burglarized safe photos I've seen or were taken by others with advice. Image
ISM Jeweler's safe on display floor of safe company. Attacked with oxyfuel torch. This is Hollywood tier non-sense and would never work on this type of safe. Image
Image
Image
Image
Photo someone took of an attempted peeling attack. Safe peeling is old school method of prying at a corner to separate layers and peel the safe open. Mainly a risk to fire safes and junk gun safes which are NOT burglary safes. Image
Read 10 tweets
Jun 23
The SCTP protocol on Linux provides a reliable and stealthy way to access Linux. In this thread I'm going to demonstrate a simple SCTP backdoor and how it can be missed by security teams. Then I'll show you how to look for this kind of activity. Image
SCTP is a protocol mainly used for telcos. It provides reliable transport like TCP, but is not TCP. Be aware that network monitoring may not be paying close attention to SCTP and packet filters can be mis-configured to not block it.
The main thing to know is that SCTP is enabled on heaps of Linux systems but it's rarely used. So if you see it being used, and you are not a telco, you need to be paying attention.
Read 12 tweets
Jun 15
The /proc/net/packet file on Linux shows you all open raw sockets that are grabbing network traffic. I'm going to show you what is in this file and provide a script that lists all processes sniffing traffic to help find malicious sniffers. Image
Image
The /proc/net directory contains files that shows protocol use on Linux. The /proc/net/packet file shows you all open raw/packet sockets which means the process is sniffing traffic. The file shows you open inodes and who owns them, but doesn't list the process doing the deed. Image
This file is stiched together with tools like lsof to show process data, but it can be useful to do it yourself or with a simple script to make sure you are getting the data directly and avoiding processes that may manipulate lsof, netstat, or ss output to hide.
Read 9 tweets
Mar 27
This new Linux script from THC will encrypt and obfuscate any executable or script to hide from on-disk detection. I'm going to show you how to detect it with command line tools in this thread.

github.com/hackerschoice/…Image
First, it only encrypts the binary at rest on disk. It is not encrypting the running process. This will evade legacy file scanning with YARA, etc. that is unreliable on Linux and I don't recommend using. The running process has no encryption so that is our detection target.
I encrypted a netcat binary. See the directory of encrypted and unencrypted binaries? Notice the size, and also notice I gzipped the binaries. Encrypted binaries do not compress well. This is a cheap "is this encrypted or not" check. Image
Read 12 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us!

:(