← Prompts
Reference System Prompts Collection

![[Pasted image 20231202081040.png]]

#shell #payload #hacking [source](https://academy.hackthebox.com/module/115/section/1101) ![[Pasted image 20231202081040.png]] A `shell` is a program that provides a computer user with an interface

#shell #payload #hacking [source](https://academy.hackthebox.com/module/115/section/1101)

![[Pasted image 20231202081040.png]]

A `shell` is a program that provides a computer user with an interface to input instructions into the system and view text output (Bash, Zsh, cmd, and PowerShell, for example). As penetration testers and information security professionals, a shell is often the result of exploiting a vulnerability or bypassing security measures to gain interactive access to a host. We may have heard or read the following phrases used by people discussing an engagement or a recent practice session:

- `"I caught a shell."`
- `"I popped a shell!"`
- `"I dropped into a shell!"`
- `"I'm in!"`

Typically these phrases translate to the understanding that this person has successfully exploited a vulnerability on a system and has been able to gain remote control of the shell on the target computer's operating system. This is a common goal a penetration tester will have when attempting to access a vulnerable machine. We will notice that most of this module will focus on what comes after enumeration and identification of promising exploits.

---

## Why Get a Shell?

Remember that the shell gives us direct access to the `OS`, `system commands`, and `file system`. So if we gain access, we can start enumerating the system for vectors that may allow us to escalate privileges, pivot, transfer files, and more. If we don't establish a shell session, we are pretty limited on how far we can get on a target machine.

Establishing a shell also allows us to maintain persistence on the system, giving us more time to work. It can make it easier to use our `attack tools`, `exfiltrate data`, `gather`, `store` and `document` all the details of our attack, as we will soon see in the proceeding demonstrations. It's important to note that establishing a shell almost always means we are accessing the CLI of the OS, and this can make us harder to notice than if we were remotely accessing a graphical shell over [VNC](https://en.wikipedia.org/wiki/Virtual_Network_Computing) or [RDP](https://www.cloudflare.com/learning/access-management/what-is-the-remote-desktop-protocol/). Another significant benefit of becoming skilled with command-line interfaces is that they can be `harder to detect than graphical shells`, `faster to navigate the OS`, and `easier to automate our actions`. We view shells through the lens of the following perspectives throughout this module:

|**Perspective**|**Description**|
|---|---|
|`Computing`|The text-based userland environment that is utilized to administer tasks and submit instructions on a PC. Think Bash, Zsh, cmd, and PowerShell.|
|`Exploitation` `&` `Security`|A shell is often the result of exploiting a vulnerability or bypassing security measures to gain interactive access to a host. An example would be triggering [EternalBlue](https://www.cisecurity.org/wp-content/uploads/2019/01/Security-Primer-EternalBlue.pdf) on a Windows host to gain access to the cmd-prompt on a host remotely.|

Sign in to view the full prompt.

Sign In

Classification

Reference Documentation, cheatsheets, setup guides
Scope Global
All AI interactions
Triggered Activates on context match -- file patterns, topics, working state