Rootkits, Trojans and Malware on Red Hat Enterprise Linux
Rootkits, trojans, and other forms of malware have been around for a long time, and new strains are regularly created. These creations include newer malware, known as ransomware, which encrypts users’ data asking for funds before restoring access to the data.
Worms typically exploit known vulnerabilities, identified with CVE numbers, poor configuration, weak credentials, etc. Keeping your system up to date with security fixes when they become available is the best way to limit your exposure to worms. Most worms are associated with a particular piece of software they exploit, and with a particular vulnerability (CVE) in that software. In such a case, checking if your system is vulnerable to that CVE informs you if it is vulnerable to that worm.
By contrast, rootkits and trojans are typically installed post-exploitation, or rely on tricking users into running malicious programs. Following strong security practices, as outlined below, is the best way to protect your systems from all kinds of malware.
Periodically, a particular strain of malware receives prominence in the media, leading to questions about whether a particular software suite is vulnerable to it, or how its presence might be detected. Typically, being vulnerable to a particular malware requires having fallen behind on security updates, deployed weak configuration, or allowed users to run untrusted software.
Compromise by malware usually presents the same indicators in logs and monitoring as compromised by an attacker. The Intrusion Detection System [IDS] may also raise alerts. If any indication of compromise is detected, the first point of escalation must be your organization’s security team. They have processes to preserve any necessary evidence and restore the system to safe, working order, which will usually involve complete erasure of its storage and reinstallation or restoration from a trusted backup.
The most common vectors used by attackers are social engineering and the leverage of one or more available flaws. As such, to reduce the chances of being compromised, it is strongly recommended to strictly follow common security best practices. Among other practices:
- Make sure you are installing software/packages from trusted sources only, and that they are regularly updated with the latest available security fixes (see RHEL7 Security Guide, Chapter 3; RHEL8 Managing and Monitoring Security Updates)
- Thoroughly review configurations and their implications (see RHEL7 Security Guide, Chapter 4; RHEL8 Hardening Guide)
- Limit exposure of test/staging/development/evaluation systems. Ensure that production and other systems are never exposed to one another, and that production data is never used in test systems without adequate anonymization & sanitization.
- Ensure you have an adequate backup solution with proper backup rotations and regular restore testing. Ensure adequate controls are in place to protect backup infrastructure from ransomware or other attacks.
- Ensure passwords are strong, are regularly changed, and remain under the control of the user
- Train and remind users to strictly follow safe behaviour (e.g., avoid clicking untrusted URLs or executing untrusted programs, etc.).
- Grant only the minimum necessary permissions to users and processes. Diligently apply principles of least privilege and separation of responsibilities.
- Consider using signature based detection methods to detect malware or network traffic signatures that are not yet implemented into available antivirus programs.
- Enforcing of SELinux policies can provide hardening capabilities that limit exposure and risk of compromise for a system.
If any suspicious behaviour of a system is detected, system administrators should immediately alert their company’s computer security team, to perform a complete analysis.
For particular articles concerning historical malware
- HiddenWasp - https://access.redhat.com/solutions/4192011
- CrossRat - https://access.redhat.com/solutions/3336311
- Erebus - https://access.redhat.com/solutions/3094421
- Drovorub / Drovorun - https://access.redhat.com/articles/5320961
- Trickbot - https://access.redhat.com/solutions/5551661
The advice in this article is relevant to the following published articles;
Published By | Article Link | Month/Year |
---|---|---|
The BlackBerry Research and Intelligence Team | Decade of the RATs: Novel APT Attacks Targeting Linux, Windows and Android | April/2020 |
The FBI & NSA | Drovorub Malware (PDF) | August/2020 |
ZD Net | Linux version of RansomEXX ransomware discovered | November/2020 |
Intezer | New Linux Backdoor RedXOR ... | March/2021 |
NetLab | RotaJakiro: A long live secret backdoor ... | April/2021 |
TrendMicro | Bash Ransomware DarkRadiation Targets Red Hat- and Debian-based Linux Distributions | June/2021 |
Intezer | Vermilion Strike: Linux and Windows Re-implementation of Cobalt Strike | September/2021 |
Deep Instinct | BPFDoor Malware Evolves – Stealthy Sniffing Backdoor Ups Its Game | May/2023 |
haxrob | GTPDOOR - A novel backdoor tailored for covert access over the roaming exchange | Feb/2024 |
Other articles of interest
Please note that some of these articles may be outside of the Scope of Support.
- Red Hat Enterprise Linux 8: Managing and Monitoring Security Updates
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/managing_and_monitoring_security_updates/index - Red Hat Enterprise Linux 8: Security Hardening Guide
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/managing_and_monitoring_security_updates/index - Red Hat Enterprise Linux 7 Security Guide
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/index - Red Hat Product Security Center
https://access.redhat.com/security/ - Is it possible to limit yum so that it lists or installs only security updates?
https://access.redhat.com/solutions/10021 - What rootkit scanners are available in Red Hat Enterprise Linux?
https://access.redhat.com/solutions/21572 - What to do if a server is hacked? Will Red Hat assist with the development of security rules and policies and root cause? https://access.redhat.com/solutions/769253
Comments