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):
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:
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:
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).
1/ We recently had an interesting #Azure case where the TA, instead of creating a new Inbox Rule, added email addresses of interest to the list of blocked senders and domains.
The incoming emails will get flagged as spam and moved to the Junk email folder. 📂
🧵
2/ Here is a screenshot from Outlook web access
(the view might differ, as, for example, here on the screenshot from the theitbros [1])
1/ Customer receives an email from a network monitoring device that a host is supposedly infected with a #CoinMiner. The Task Manager on the said system shows the following screenshot 🤕.
A story of an unpatched system, incorrect scoping, and 🍀. 🧵
1/ I used #AutoRuns v14.09 (GUI) in my lab setup but noticed that it failed to find (or display) the malware in the Startup folder, although the file is there (screenshot below).
I checked back and forth, searched manually for the file, and restarted the OS and AutoRuns.
🧵
2/ With #Velociraptor, I ran the hunt Sysinternals.Autoruns, and with the CLI version of AutoRuns, the malware is found in the Startup folder.
3/ The same for the #Velociraptor hunt Sys.StartupItems.
1/ Real-World #PingCastle Finding #13: Allow log on locally
➡️ Domain Users are eligible to log into DC's 🤯🙈
"When you grant an account the Allow logon locally right, you are allowing that account to log on locally to all domain controllers in the domain." [1]
"If you do not restrict this user right to legitimate users who must log on to the console of the computer, unauthorized users could download and run malicious software to elevate their privileges." [1]
3/ I encountered this finding several times in our AD assessments, so you better check your settings in your domain right now (better safe than sorry 🔒).