{"id":18401129,"url":"https://github.com/d3fenderz/linux_security","last_synced_at":"2025-04-12T17:00:18.823Z","repository":{"id":65226013,"uuid":"579774800","full_name":"d3fenderz/linux_security","owner":"d3fenderz","description":"Attack / Defense Linux  🧢","archived":false,"fork":false,"pushed_at":"2023-04-13T13:28:35.000Z","size":100,"stargazers_count":2,"open_issues_count":0,"forks_count":1,"subscribers_count":0,"default_branch":"main","last_synced_at":"2025-02-16T03:25:57.267Z","etag":null,"topics":["blueteam","forensics","guide","linux","pentesting","security","security-guide","ubuntu"],"latest_commit_sha":null,"homepage":"","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"gpl-3.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/d3fenderz.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2022-12-18T21:45:51.000Z","updated_at":"2024-11-10T15:43:26.000Z","dependencies_parsed_at":"2024-11-06T03:05:17.958Z","dependency_job_id":"f786750f-829f-4165-a759-d175fc5e3f0e","html_url":"https://github.com/d3fenderz/linux_security","commit_stats":null,"previous_names":["d3fenderz/linux_security"],"tags_count":1,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/d3fenderz%2Flinux_security","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/d3fenderz%2Flinux_security/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/d3fenderz%2Flinux_security/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/d3fenderz%2Flinux_security/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/d3fenderz","download_url":"https://codeload.github.com/d3fenderz/linux_security/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":248602273,"owners_count":21131613,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["blueteam","forensics","guide","linux","pentesting","security","security-guide","ubuntu"],"created_at":"2024-11-06T02:37:48.670Z","updated_at":"2025-04-12T17:00:18.728Z","avatar_url":"https://github.com/d3fenderz.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# Linux Security\n\n![GitHub last commit](https://img.shields.io/github/last-commit/d3fenderz/linux_security?label=last%20update%3A)\n\n## Transparency\n\nI'm a senior DEV, a cybersec enthusiast and writer, and a very bad sysadmin on my free time. Everything you will read here is documented.\n\nI'm not trying to speak with authority, but I will show you how to hack **and** defend your machine or a server. Linux is fantastic but not inherently secure. It does not mean package managers and update cycles are not great.\n\nSecurity requires knowledge and time. Regardless of your level of experience, it's easy to fail. Nobody's perfect.\n\nLet's review the basics and mitigate classic attacks.\n\n## Some Linux myths\n\n### Linux is more secure than ***\n\nThis sentence is problematic, as it does not tackle the problem correctly. While there are way more CVEs and exploits associated with Windows, for example, it's usually related to specific programs and apps that do not run on Linux natively.\n\nThen, it would be interesting to count all the vulnerabilities that have been fixed vs. those that remain unpatched.\n\nHowever, the comparison between the two OSes does not make sense, to me. If you're a threat actor you probably want to spread your malware everywhere and target the most popular OS. If you need to target your victims more specifically or to attack Cloud infrastructures, you can build Linux malware, as well.\n\nThanks to modern programming languages, it's easier to generate cross-platform scripts.\n\nIt depends on the goals.\n\nLast but not least, unpatched or misconfigured Linux machines are vulnerable.\n\n### Default configurations are enough\n\nJust no.\n\n### The market share is ridiculous, so it's not a target\n\nIt might look very small if you only consider the end-users, a.k.a. the casual users, but it's used everywhere in reality:\n\n* IoT devices\n* Cloud-based architectures\n* Cars\n* Military infrastructures\n* Servers\n* Systems that drive critical tasks such as Air Traffic Control\n* public clouds\n\nMany other devices rely on Linux distributions and do not always bother with encryption, software patches, and other security measures, making them attractive targets to reach other instances.\n\n### Linux is open-source, so all bugs are addressed quickly\n\nOpen-source brings trustworthiness and auditability, which is undeniably beneficial for users, especially if you care about privacy, but it does not mean all security holes are fixed _automagically_.\n\n[Pwnkit](https://github.com/berdav/CVE-2021-4034) has finally been patched after more than 12 years of active exploitation and affect all modern Linux distributions. This memory corruption is particularly easy to exploit on vulnerable machines.\n\n### I'm invicible with my distro for hackers\n\nSome people seem to believe installing Kali Linux or one the numerous alternative Linux distributions for hackers and security researchers is enough to be incognito or keep attackers away.\n\nIt's definitely not the case. For instance, it does not mask your real IP and need to be configured correctly. Don't get that false impression of security that can lead you to very bad outcomes.\n\n## Linux distributions vs. Desktops vs. package managers\n\nA Linux distribution, or \"distro,\" is an OS that contains the Linux kernel and a package manager. For example, Ubuntu, one of the most popular distros, is a Debian-based OS that relies on `dpkg` to manage the packages in the system. `APT` is the interface that provides command lines to search, install, update, remove, or list packages in Debian-based distros.\n\nHowever, Linux has literally hundreds of distros, and many other associated package managers. For example, Arch Linux uses [pacman](https://wiki.archlinux.org/title/Pacman), which has a very different approach of release cycles and dependency management.\n\nWhile the most popular distros are pretty-well maintained and many people give their time to patch others, some remain unpatched and others get simply abandoned.\n\nThe Desktop environment is the graphical user interface (GUI). There are popular desktops, such as KDE, Gnome, or Mate, but many flavors and derivative solutions exist as well. The Desktop is not only for the look and feel, and usually provides specific functionalities. You don't get the same catalog with KDE and Gnome, for example, and some programs may not be compatible with all Desks.\n\nOnce you have installed your favorite distro, it's possible to change the default Desktop.\n\n## Linux essentials for hackers\n\nYou can [start with the Fundamental Manual](https://man7.org/tlpi/index.html) if you're motivated.\n\nOtherwise, and even if there are tons of other great resources, I appreciate the series by [HackerSploit](https://www.youtube.com/watch?v=T0Db6dVYyoA): very concise.\n\nIt's not exhaustive, but it's a great synthesis.\n\nI've also read [this book](https://a.co/d/3Hfp7S9) and [this other one](https://a.co/d/dqmntNz)\n\n## Installing Linux for cybersecurity\n\nOf course, [Kali Linux](https://www.kali.org/) is a fantastic distro to create your own lab. If you don't need all tools and you are a beginner, you might want to install a Debian-based distro or Debian itself instead. You can use my repos [godebian](https://github.com/d3fenderz/godebian) to install a few packages.\n\nI would also recommend a virtual machine to isolate your environment.\n\nOnly attack machines that you own or with explicit authorization. Otherwise, you'll take the path of cybercriminals, and good luck.\n\n## Attacking Linux\n\n### Disclaimer\n\nThere are so many attacks that it's impossible to list them all. Here is a quick overview.\n\n### Linux malware\n\n[2020 set a record for new Linux malware families](https://www.intezer.com/blog/cloud-security/2020-set-record-for-new-linux-malware-families/) and it keeps increasing.\n\nThese are mostly targeted campaigns, but it shows that threat actors will target any system if that's necessary. Besides, Linux servers are everywhere and power most websites and applications, not to mention cloud infrastructures.\n\nThe other major trend is the rise of cryptominers. Because mining cryptocurrencies requires heavy CPU utilization, threat actors like to distribute the load to unsuspecting victims.\n\nCybercriminals use specific rootkits to hide these processes on the targeted machines/servers. Otherwise, it would be detected quickly. It does not prevent the performance issues, so the victims know something is wrong, but it's pretty hard to identify the exact processes involved.\n\nIf you don't find it, you can't remove it easily.\n\n### Why Linux internals are so important\n\nI strongly encourage you to study Linux internals in details, like what is a process, the difference between processes, threads, and jobs, or what is the Linux Kernel and how user mode programs call it. It's not in the guide, as it cannot be done quickly, IMHO. \n\nWithout this knowledge, you cannot understand memory corruption, kernel exploits, buffer overflows, and other low-level interactions correctly, IMHO.\n\nThe ultimate goal of these attacks is usually to gain unauthorized access to privileged processes, perhaps root privileges.\n\n### Kernel exploits\n\nYou may have read names like \"DirtyCow\" or \"DirtyPipes.\" These are kernel exploits that are actively exploited by cybercriminals on unpatched machines.\n\nA very quick and efficient way to exploit the kernel is to use [automatic scanners](#enumerate-like-an-attacker). If you want to do it manually, you can start by checking the current version of the kernel with one of these commands:\n\n```\nuname -r\nhostnamectl | grep Kernel\n```\n\nThen, it's not very complicated to relate it with a known exploit, as many CVEs have public POCs (proof of concept). A list of vulnerable kernel versions and exploits can be found [here](https://github.com/lucyoa/kernel-exploits).\n\nYou can also check dedicated platforms, if the most recent ones are not listed.\n\nIt should be noted that kernel protection has been improved over the past years, which mitigates what an attacker can do and might even eliminate old exploits. Still, there are CVEs associated with the Linux kernel in 2023.\n\n### Memory corruption\n\nHacking memory is often rewarding. Some credentials may appear in clear text, and you can even gain root privileges in the best-case scenario. Linux has special directories such as `/proc/` and `/dev/mem` that exposes memory processes, for example.\n\nTo understand how it works, read about virtual memory (~ extended memory with hard disk) vs. physical memory (~ RAM).\n\nPwnkit, a popular Linux kit for memory corruption, allows root access with an unprivileged account. The bug has been known for years (12), but the patch is relatively recent (at the time of writing).\n\nDon't panic, though. Memory protection has also improved, sometimes making classic attacks impossible in real-world conditions.\n\nThe bad news is that most documented POCs are outdated (~ patched).\n\nHowever, you may google terms like [buffer overflow](https://www.cloudflare.com/learning/security/threats/buffer-overflow/) or [Heartbleed](https://xkcd.com/1354/) for practical examples.\n\n### Privilege escalation\n\n[Read HackTricks](https://book.hacktricks.xyz/linux-hardening/privilege-escalation)\n\nBookmark [GTFOBins](https://gtfobins.github.io/).\n\n### Evasion\n\nRead [HackerSploit Red Team Series - Evasion](https://www.linode.com/docs/guides/linux-defense-evasion-hiding-linux-processes/).\n\n### Persistence\n\nOne of the multiple benefits of evasion can be persistence, which means you can stabilize a RCE (Remote Code Execution) or exfiltrate information despite counter-measures.\n\nAttackers can achieve that in various ways, such as modifiying the targeted OS configuration, injecting payloads in memory, or even using the filesystem. Each approach has its cons:\n\n* config updates can be detected\n* memory injections are harder to detect but die with the session\n* the filesystem leaves tracks\n* many persistence mechanisms require admin privileges \n\nCheck [HackerSploit Red Team Series - Persistence](https://www.linode.com/docs/guides/linux-red-team-persistence-techniques/) for practical examples and further explanations.\n\n### Physical attack: the recovery abuse\n\nMisknown hacking method on Linux that relies on the single user mode:\n\n#### Context and disclaimer\n\nThis part has some limitations, especially with recent hardware that offers interesting security features, like additional authentication.\n\nI'm totally aware that when an attacker has access to the machine it's hard to completely secure it, but this easy method should be more documented, IMHO.\n\n#### Quick steps to bypass Linux login\n\n1. reboot and press `shift` just after to start the GRUB menu\n2. select \"Advanced options for Ubuntu\"\n3. select a version that contains \"(recovery mode)\"\n4. select the root console or shell prompt in the recovery menu\n5. type `id` in the console to see check if you're root, but if you see something similar to `root@pc`, it's done\n6. navigate to the folder of your choice, as you have now the highest privileges\n\n#### High probablity\n\nWhile this scenario won't work all the time, it's highly probable, to me, especially if you consider an average user and a classic installation. Not everybody will change root password, encrypt the disk, or monitor such modifications, as the `sudo` command allows to perform most administrative tasks.\n\nBesides, Ubuntu provides a graphical interface to handle all operations, for example, update and maintenance.\n\n#### Mitigation\n\nEven if the first one should be enough for this particular case, you may combine all tips for better security:\n\n* Do not only consider the `/home`, use full disk encryption\n* Set admin password in the BIOS\n* Set user password in the BIOS and require it during the boot\n\n#### Don't touch the GRUB\n\nAfter some tests, I don't recommend setting a GRUB password or removing the GRUB rescue anymore.\n\nWhile it's possible and might work in your case, it's the most hacky approach and not the most efficient one. There's a significant risk to mess up the booting sequence, which can be hard to recover.\n\nIn another perspective, dual boot configurations are bad from a security perspective.\n\n## Inspecting Linux\n\n### Manual inspection\n\n#### Useful commands\n\n```\n# basic OS information\nuname -a # all info\nuname -r # only the kernel version\n\n# get info about the filesystem and mounted devices \ndf -h\n\n# scroll in the file that contain all users\nless -r /etc/passwd\n\n# scroll in the file that contain all encrypted passwords\nsudo less -r /etc/shadow\n\n# who is currently logged in?\nw -huis\n\n# something suspicious in recent connections?\nlast -Fw\n\n# network info and ports\nlsof -i TCP # show TCP activity\nlsof -i4 # ipv4 activity\nlsof -i6 # ipv6 activity\nlsof -i -n # open connections\nnetstat -ano\n\n# inspect processes\nps aux\nps aux | grep root # pipe to search a specific term\n\n# Inspect history\nls -alh $HOME/.*history\nless -r $HOME/.bash_history\n\n# /var/log\n# auth.log*\n# syslog*\n# kern.log\n\n# files opened using SSH\nsudo lsof -r -i :22\n\n# journal\njournalctl -S -4h\n```\n\n#### Cheat sheet\n\nLearn additional commands in [the Blue Sheet](https://github.com/d3fenderz/blue_sheet)\n\n#### Quick Todo list inspection\n\n* check file and folder permissions: this is critical, especially for dotfiles and system binaries\n* check the sudo config (e.g., available commands for sudoers), `/etc/passwd`, and `/etc/shadow`\n* check mounted drives\n* check the `$PATH`\n* check the CRON jobs (e.g., commands containing wildcards)\n* use `tcpdump` to sniff the traffic or more advanced networking tools\n* check the `~/.ssh/` directory\n\n### Memory Inspection\n\nThe big caveat with tools is that it does not teach you how to analyze memory correctly and where to look. Besides, OSS (Open-Source Security) can be tricky, especially with abandoned or deprecated projects. Still, tools are important, and you have to know some, at least.\n\nMemory inspection can be hard. One of the most popular tool to analyze memory dumps is [Volatility](https://github.com/volatilityfoundation/volatility/wiki/Linux).\n\nYou might also appreciate [Volshell](https://volatility3.readthedocs.io/en/latest/volshell.html).\n\nI also like the `smem` utility. It's a very light command-line memory tool that can generate various reports on memory usage on a Linux system.\n\n### Automate Inspection\n\n#### Enumerate like an attacker\n\nWhy not using CTF tools to spot vulnerabilities?\n\n* [Lynis](https://github.com/CISOfy/lynis)\n* [Linux Exploit Suggester](https://github.com/The-Z-Labs/linux-exploit-suggester)\n* [linPEAS](https://github.com/carlospolop/PEASS-ng/tree/master/linPEAS)\n\n#### Network utilities\n\nThese free programs can ease network inspection significantly:\n\n* [htop](https://htop.dev/)\n* [nethogs](https://github.com/raboof/nethogs)\n* [nagios](https://www.nagios.org/)\n* [tcpflow](https://github.com/simsong/tcpflow)\n* [tcpreplay](https://github.com/appneta/tcpreplay)\n* iftop\n* [netfilter \u0026 iptables](https://www.netfilter.org/)\n\n### 7 Forensic resources to go further\n\n* [LinuxForensics](https://linuxdfir.ashemery.com/): Everything related to Linux Forensics\n* [Practical Linux Forensics](https://a.co/d/gs1bxga)\n* [The art of Memory Forensics (cross-platform)](https://a.co/d/8GN7pTI)\n* [A Linux Forensics Starter Case Study](https://www.forensicfocus.com/articles/a-linux-forensics-starter-case-study/)\n* [Linux and disk forensics](https://resources.infosecinstitute.com/topic/linux-and-disk-forensics/)\n* [Count Upon Security: Intro To Linux Forensics](https://countuponsecurity.com/2017/04/12/intro-to-linux-forensics/)\n* [TryHackMe: Linux Server Forensics](https://tryhackme.com/room/linuxserverforensics)\n\n## Hardening Linux\n\n### Manual hardening\n\n#### Quick Todo list to secure your machine\n\nIn my experience, Linux requires manual hardening. You may apply the following for basic security hygiene:\n\n* use full disk encryption, not just for your ~/home folder\n* disable any telemetry (e.g., disable system reports, don’t send crash reports) and file history if you don’t need them, which is likely\n* disable wireless connections if you don’t need them (e.g., Bluetooth, WiFi)\n* get rid of useless services (e.g., in privacy settings) and packages, and close unused ports\n* cover your camera\n* lock down the desktop, but also the BIOS (e.g., set administrator password)\n* consider moving to SELinux\n\n#### FDE (Full Disk Encryption)\n\nDepending on your hardware, disk encryption will not be the same. For example, it may allow you to encrypt the `/home` folder only, which is a good start, but full disk encryption is better.\n\nWhile it's a bit more constraining, as you need to provide a key to unlock your machine every time you start/restart (before the login/password), it's compatible with UEFI Secure Boot and TPM 2.0, at least in Ubuntu 20.04.\n\nIf it's available, enable it during install. It's possible to do it afterwards, but it's a bit more technical. LUKS \u0026 LVM can do that. More advanced users may appreciate this [reencrypt](https://manpages.ubuntu.com/manpages/trusty/man8/cryptsetup-reencrypt.8.html) package, but backup your data before anything.\n\n#### About Secure Boot\n\nThe `Secure boot` option in the BIOS can be beneficial, but it's important to understand what it does. The goal is to prove authenticity and integrity (it verifies signatures). To protect your data from potential thefts, you need **encryption**.\n\nHowever, disabling it, for example, dual boot configurations, is not recommended, as you extend the surface.\n\n### Automate hardening \u0026 monitoring\n\nDepending on the context, you will need additional resources. Manual inspection and quick todo lists won't be enough to catch highly-evasive and targeted attacks in a corporate environment.\n\nNote that using tools does not guarantee anything, as these solutions will likely focus on compliance. Still, connecting a SIEM to your logs and programming custom alerts can help spot anomalous activities and mitigate further operations.\n\nThis guide is not meant to fight against advanced adversaries. Sometimes, there's no mitigation. However, it's not a valid reason to be nihilist. Lock everything you can while keeping the system usable.\n\n### Protect your Network\n\n#### Filter and monitor outgoing traffic\n\nIt's easy to understand why incoming traffic must be filtered, perhaps entirely blocked depending on your usage. One of the easiest ways to do that is to enable the Uncomplicated Firewall (ufw) and deny incoming traffic.\n\nHowever, you should not neglect outgoing traffic. While it's a bit more constraining to configure, there's no reason to allow all ports on out.\n\n#### Use a VPN\n\nIt's indeed not specific to Linux, but many solutions on the market are compatible with _the Penguin_. Because I'd like keep this guide agnostic, I'm not recommending a particular one, but you may use OpenVPN, as a large range of providers will provide ready-to-use configuration files and an interface for it.\n\nOn Debian-based distros, you can start with the following command:\n\n```\nsudo apt install -y openvpn bridge-utils\n```\n\nHowever, it's usually more efficient to follow the instructions provided by your client/provider. In any case, manual installations from scratch are documented.\n\nUsing a VPN is recommended to mitigate packet sniffing, improve privacy, or simply circumvent geo-blocking.\n\n#### Why people keep disabling IPv6\n\nIn very short, IPv6 solves the following problem: the number of IPv4 addresses available is limited. The number of IPv6 addresses is exponentially larger (~ 10\u003csup\u003e28\u003c/sup\u003e for IPv6 against \"a few\" billions for IPv4)\n\nThere are many other features and improvements, and the notation is not the same, but we won't see that here.\n\nMost of the time, people disable it because it's still not supported everywhere. Some VPNs and ISPs just don't support it, for example. So [if it's unavailable](https://ipv6-test.com/) for you, disable it:\n\n```\necho 'net.ipv6.conf.all.disable_ipv6=1\nnet.ipv6.conf.default.disable_ipv6=1\nnet.ipv6.conf.lo.disable_ipv6=1' | sudo tee /etc/sysctl.d/10-disable-ipv6.conf\nsudo sysctl -p\n```\n\n[Source: PrivSec](https://privsec.dev/posts/linux/protonvpn-ip-leakage-on-linux-and-workaround/#general-linux-distributions)\n\nTo learn more about IPv6 and its advantages, you can read [this guide by the NSA](https://media.defense.gov/2023/Jan/18/2003145994/-1/-1/0/CSI_IPV6_SECURITY_GUIDANCE.PDF).\n\n## Introduction to Linux servers\n\n### Why\n\nWebsites and applications are hosted on servers that run Linux distributions (not always), which means these machines must be secured.\n\nPretty much the same commands and recommendations will apply, but you will likely have to take additional measures.\n\n### Basic security\n\n* update and upgrade packages\n* remove unused packages (`dpkg --list`)\n* disable root login (`PermitRootLogin no` in `/etc/ssh/sshd_conf`)\n* applu least privileges on users and groups\n* check and disable useless startup processes (see `systemd`)\n* check and disable useless services (`systemctl list-unit-files --type=service`)\n* have a tested backup/recovery strategy (manual or scheduled backups on the same server is not recommended)\n* turn on and configure `iptables` (firewall)\n* close useless ports (`sudo ss -tulnp | grep LISTEN`, then you can block them with firewall rules)\n* disable unused services (`chkconfig {SERVICE} off`)\n\n### SELinux\n\nSE Linux can be an interesting additional layer. Be careful, though, as it's not an ordinary package and will deny access to anything that is not explicitly allowed. Ensure you don't exclude yourself from the server, which may happen to beginners in some cases.\n\nSuch approach is called a MAC system (Mandatory Access Control). The idea is to isolate privileged processes and ease security policy setup.\n\nHere's how to install it on Debian-based machines in enforce mode:\n\n```\nsudo systemctl stop apparmor\nsudo apt purge -y apparmor\nsudo apt install -y selinux-basics selinux-policy-default auditd\nsudo selinux-activate\nsudo systemctl enable auditd\nsudo setenforce 1 # 0 is for permissive mode\ncat /etc/selinux/config \nsudo reboot\nsudo sestatus\n```\n\nWe remove AppArmor because the two packages have similar purposes: isolation.\n\nUnlike the Enforcing mode, the Permissive mode does not block denied operations, but it logs them, for example, in `/var/log/audit/audit.log`.\n\n## 7 links to go further\n\nHere are useful links to go further:\n\n* [Intezer - Not Another Linux Security Blog](https://www.intezer.com/blog/cloud-security/not-another-linux-security-blog/)\n* [Linux security and system hardening checklist](https://linuxsecurity.expert/checklists/linux-security-and-system-hardening)\n* [NSA - Linux hardening](https://github.com/shaurya-007/NSA-Linux-Hardening-docs)\n* [Hacktricks - Linux privilege escalation](https://book.hacktricks.xyz/linux-hardening/linux-privilege-escalation-checklist)\n* [Linux Kernel](https://www.kernel.org/doc/html/latest/)\n* [PayloadsAllTheThings - Linux Privesc](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Linux%20-%20Privilege%20Escalation.md)\n* [Detecting Linux memfd_create()](https://sandflysecurity.com/blog/detecting-linux-memfd-create-fileless-malware-with-command-line-forensics/)\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fd3fenderz%2Flinux_security","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fd3fenderz%2Flinux_security","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fd3fenderz%2Flinux_security/lists"}