Stephan Berger Profile picture
Head of Investigations @InfoGuardAG https://t.co/A5lnFAu7eX

Jun 7, 2022, 25 tweets

1/ Linux #Hardening and #ThreatHunting

The screenshot below is from Microsoft [1] - using XorDdos as an example, we can learn a lot about Linux forensics and hardening. 🧵

#CyberSecurity

2/ XorDdos bruteforces (root) access via SSH.

Learning: Prevent logging in via SSH with passwords (use priv/pub keys instead).

Within the SSH config (/etc/ssh/sshd_config), modify at least the following two lines:

PermitRootLogin no
PasswordAuthentication no

3/ SSH can, of course, be secured in much more detail.

DigitalOcean has put together an excellent guide on this topic:

digitalocean.com/community/tuto…

4/ To examine XorDdos more closely, we download the ELF file from VT and infect our test machine with it (this file would be placed on the server after the root account has been compromised):

virustotal.com/gui/file/8a006…

5/ As seen in the first screenshot from MS, XorDdos creates various persistence mechanisms, including a cron job.

Cron jobs are one of the first things I check on a Linux system when assuming a compromise.

6/ The malware created a new entry in the /etc/crontab file - the /etc/cron.hourly/gcc4.sh file is called periodically.

Scripts called by a cron job should always be examined very carefully.

7/ Inside the shell script called by the cron job, a file is copied inside the /lib/ directory and then started.

8/ The hash sum is the same as from the started binary (/4) - according to Microsoft [1], the malware copies itself into the /lib directory, among other directories.

9/ In addition to the cron job, a new init entry was created on our (Ubuntu) machine that starts and stops the malware.

The init file gets the same name as the invoker program. The content of this init file should look at least suspicious enough to dig deeper.

10/ "After running the ELF file, uses an anti-forensic technique that hides its past activity by overwriting the content of the following sensitive files with a newline character:" [1].

11/ On our test machine, a journal is kept where all log messages are written by the journald (in the path /var/log/journal). We can export the journal for easier analysis:

journalctl --file <path>/system.journal -o export > /tmp/journal

12/ Read more about the journal from the sample chapter from the highly recommended book "Practical Linux Forensics" from @nostarchpress:

nostarch.com/download/sampl…

13/ Inside the journal, we find out from which IP address was logged in via SSH, even if other log files were deleted (see /10).

By the way, the malware does NOT delete the auth.log file (consciously or unconsciously), which we can use for forensic purposes.

14/ There are also traces of the cron job in the journal:

15/ Even though XorDdos deletes various log files, and according to Microsoft, also uses other techniques for hiding, it should be relatively easy to identify a machine infected with XorDdos.

16/ The spoofed command-line (see again [1]) can be used for hunting (there should not be too many processes running on a network that execute "cat resolv.conf").

17/ Even better is to look for the file gcc4.pid in the /var/run directory.

This value is sent to the C2 to identify the infected host uniquely.

If this file is present on a system, a deeper search must be done to check for a compromise by XorDdos.

18/ For those who have been following me on Twitter for a while.... exactly, @Sandfly! :)

We create a new sandfly where we specifically search for the file gcc4.pid on the whole file system.

19/ Our newly created Sandfly can now be selected for searching across our Linux fleet.

20/ And we get a hit (or a failure - that means the search have returned a hit).

Interestingly, the file is not stored under /var/run/, but under /run. A strict search for the fixed file path (from the IOC from MS) would not have found this file.

21/ Within the result from the Sandfly hit, we see the unique value used for sending back to the C2, indicating a true positive hit.

22/ As a last check, we take a closer look at the network connections. We see that "cat resolv.conf" has sent a SYN to an external IP address. Suspicious ;-)

23/ This IP address, in turn, brings us back to XorDdos:

virustotal.com/gui/file/00007…

24/ Also a good hunt: Searching for connections on the firewall with successful or attempted connections to a high port (like in our example to port 60000).

25/ Reference:

[1] microsoft.com/security/blog/…

Share this Scrolly Tale with your friends.

A Scrolly Tale is a new way to read Twitter threads with a more visually immersive experience.
Discover more beautiful Scrolly Tales like this.

Keep scrolling