A common objective of an adversary is to achieve remote code execution on their target hosts. This can be done in a number of ways; by finding a command execution vulnerability, leveraging memory corruption vulnerabilities, abusing valid or default accounts, …
Once an attacker is able to run unauthorized commands on a system, they can potentially use this to exfiltrate data, elevate their permissions, move laterally, install persistence, etc.
Many PoCs for command execution bugs are kind of clunky to use. They may require you to edit the source code to change commands, escaping special characters may be impossible or difficult, or it needs to be encoded in a certain manner that isn’t straightforward for a human.
To elevate the attacker’s user experience, they will often run reverse shell or bind shell payloads against their victims. This presents the attacker with a session similar to logging in at the system’s console or over SSH and being presented with an interactive shell, which is far more convenient than modifying some shit tier Python PoC.
To take it up another step, attackers may upgrade their shells to fully-interactive ttys: https://blog.ropnop.com/upgrading-simple-shells-to-fully-interactive-ttys/
The techniques contained within the blog post above can be leveraged as detections because the chances of these techniques being used legitimately are remarkably low.
Depending on the software available on a victim host, the attacker may use different LOLBAS, creating one-liners to execute their bind/reverse shells. There are several repositories on the internet of examples of these using a multitude of tools and scripting langauges.
Often attackers re-use open-sourced examples of these one-liners by copying and pasting them. Defenders will regularly see verbatim examples of these types of shell code featured in blogs, GitHub repositories, mailing lists, etc. used in real-world attacks. This has sparked great debate in the ethics of creating OSTs.
Defenders can search for suspicious process parent/child relationships where an unexpected program runs a shell, or by using somewhat brittle methods of parsing command lines for indicators that may identify a command line as containing a reverse shell.
Defenders absolutely should be making detections based on real-world examples of malicious code, even though they can tend to be brittle detections. It can be easy, effective, and straightforward but not an ultimate solution.
Attackers can also modify them with obfuscation techniques such as changing variable/funciton names, order in which variables are declared, the order of operations of the one-liner if possible, adding bogus dummy operations or comments, using encoding such as base64, and a ton of other obfuscation methods. In many cases, even very slight alterations can bypass an existing detection.
Attackers when using these one-liners can use them verbatim for plausible deniability purposes and to muddy attribution efforts.
Follow through activity conducted by an attacker over a shell can be used for attribution. Attackers often make mistakes when typing, use words or misspellings that may reveal their national origin, or use one-liners that are somewhat unique, but used elsewhere.