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).
/2 The TA used the leaked credentials from an employee of the company to connect to the internal network via Citrix Netscaler.
Using the Velociraptor @velocidex Hunt Windows.EventLogs.RDPAuth, we first gather logon data from the systems in our network. Below the description.
3/ Although the hunt says in the description "Best use of this artifact is to collect RDP and Authentication events around a timeframe of interest" this Velo-Search can also be used wonderfully for generic hunting.
AnyDesk
Splashtop
Atera
TeamViewer
SupRemo
ScreenConnect
Remote Utilities
After breaching a network, attackers install, besides the obvious backdoors, other (legitimate) remote desktop products that can be used to re-enter the network. 🧵
2/ The list above is not exhaustive, but defenders and incident responders must make sure that the installed remote desktop products were installed by the customer and not by an attacker.
3/ Especially in the case of an IR investigation, it is imperative to hunt for these products in the network.
But also proactively during a compromise assessment - the credentials for the remote solution could also have been leaked on a private PC (-> if possible, use MFA).
1/ @CISAgov published the 2021 Top Routinely Exploited Vulnerabilities.
We also had another IR case not too long ago where the attackers connected via Forti-VPN where the credentials for that account were in the big credentials leak - in 2022! 🤯
The credentials were (potentially) obtained from systems that remained unpatched against CVE-2018-13379 at the time of the actor's scan. Even if the devices have since been patched, they remain vulnerable if the passwords are not reset. 🚨
3/ Actually, this should have been done a loooooong time ago, but companies should check (or have checked) whether credentials from their users are present in this leak.
And (or) change all users' passwords if necessary, together with a review of the VPN configuration.
2/ exiftool works very well to find out the path and command line arguments of the malicious LNK file:
3/ The analyzed sample from @Netskope calls PowerShell directly. However, in our sample, cmd.exe is called first, then PowerShell with a base64 encoded command argument.