10.1 Forward vs Reverse Shells, Beaconing, Metasploit, Cobalt Strike

10.1 Forward vs Reverse Shells, Beaconing, Metasploit, Cobalt Strike

Quick Answer: A forward (bind) shell waits on the victim for the attacker to connect in. A reverse shell has the victim connect out. Reverse shells often succeed where bind shells fail because many networks allow outbound Hypertext Transfer Protocol Secure (HTTPS) while Network Address Translation (NAT) and firewalls block unsolicited inbound traffic. Beaconing Command and Control (C2) is quieter than an always-open reverse shell: the host checks in on a schedule. Security Operations Center (SOC) analysts recognize Metasploit and Cobalt Strike by traffic and host artifacts—not by operating those frameworks.

This independent study material covers Command and Control topics that appear in TryHackMe Security Analyst Level 1 (SAL1) training content. The exam point is recognition and detection: you identify shell direction, explain why reverse shells evade typical perimeter rules, distinguish beaconing from an interactive reverse shell, and name defender-visible indicators associated with common C2 frameworks. This section does not teach how to generate payloads, start listeners, or operate offensive tooling.

What Command and Control is for a SOC analyst

After initial access, an attacker usually still needs a way to issue commands, pull additional tools, and move data. That remote control channel is Command and Control (C2). In MITRE ATT&CK language this maps to tactic TA0011. You will not be asked to stand up C2. You will be asked to notice when a host is talking to something that looks like an operator's server.

At Level 1, treat C2 as a communications pattern plus host evidence:

• Who initiated the Transmission Control Protocol (TCP) or HTTPS session?
• Is the session long-lived and interactive, or periodic and small?
• Does the destination look like a business service, or an odd domain, a newly registered name, or a raw IP address?
• Which process on the endpoint owns the connection?

Those four questions separate a reverse shell from a bind shell, and an interactive shell from a beacon, without requiring you to reconstruct the attacker's toolkit.

Forward (bind) shells versus reverse shells

A shell here means a remote command channel, not the Windows Command Prompt as a product name. Direction—who starts the connection—is the distinction SAL1 training content emphasizes.

Forward shell (also called a bind shell)

In a forward shell (bind shell), malware or a planted listener binds a port on the victim and waits. The attacker then initiates an inbound connection to that port and receives a command channel. From the network's point of view, the first SYN comes from outside (or from another internal host) toward the victim.

Bind shells show up when the victim is directly reachable: a lab virtual machine with a public IP, a cloud instance with a wide-open security group, or an attacker who is already on the same local area network (LAN) during lateral movement. They fail in the common enterprise case. The workstation sits behind NAT, the firewall default is deny inbound, and nothing is published on the attacker's chosen port. A bind shell that nobody can reach is useless to the operator—and that is why reverse shells dominate real workstation intrusions.

Reverse shell (victim-initiated)

In a reverse shell, the compromised host connects outbound to an attacker-controlled listener. The attacker does not need an inbound path to the victim. Once the outbound session is up, commands travel back over that same connection.

This is why reverse shells often bypass NAT and egress-allow firewalls:

1. NAT rewrites private source addresses for outbound flows and tracks the return path. The victim's outbound SYN creates the state; replies are allowed as established traffic. The attacker never needs a port mapped to the workstation.
2. Egress-allow policy is the usual perimeter design: block unsolicited inbound, allow users out to the web (especially TCP 443). A reverse shell that looks like an ordinary HTTPS client rides that allow rule.
3. Stateful inspection treats the reverse-shell TCP stream as a connection the internal host started, so return packets are not classified as new inbound.

A useful trap: "the firewall is working" does not mean C2 is impossible. A firewall that is doing its job for ingress can still pass victim-initiated C2. Detection therefore shifts to which process went out, to where, and how often—not to whether inbound ports are closed.

Why the exam stresses reverse shells

Picture a laptop on a corporate wireless network. It has a 10.x.x.x address. The perimeter firewall publishes mail and virtual private network (VPN) services, not random high ports on that laptop. An attacker on the internet cannot complete a bind-shell handshake to that host. If malware on the laptop dials out to an external listener on TCP 443, NAT creates a mapping, the firewall sees an internal-to-external HTTPS-like flow, and the operator now has a channel.

That is the SAL1 idea in one sentence: reverse shells succeed because the victim is allowed to leave, not because the attacker is allowed to enter.

Analysts still hunt bind shells on internally reachable assets: a jump box with an unexpected command interpreter listening on TCP 4444, or a server whose cloud security group suddenly allows the world to a high port. Direction is contextual. Pick the model that matches the network path in the question or the alert.

The diagram below compares the two directions. Use it as a triage mnemonic: if the first packet is outbound from the victim, think reverse shell or beacon. If the first packet is inbound to a newly listening port, think bind/forward shell.

C2 frameworks named in SAL1 training content: what defenders see

SAL1 training content names Metasploit and Cobalt Strike as example C2 frameworks. Treat them as families of artifacts, not as products you configure. You do not need handler syntax. You do need to know why SOC queues mention these names.

Metasploit, as seen in telemetry

Metasploit is a widely used exploitation and post-exploitation framework. In detections and threat intelligence, it often appears as:

• Default or historical ports such as TCP 4444 on a Meterpreter-style listener. Defaults are frequently changed; a hit is a clue, not proof.
• Staged payloads that fetch a second stage over the C2 socket, producing a small initial connect followed by a larger transfer.
• Process injection and unusual parent/child pairs, such as a user application spawning a shell that then holds a network socket.
• Public signatures and YARA rules that match well-known Metasploit stagers when attackers left defaults in place.

A reverse shell spawned through Metasploit is still a reverse shell: the victim connected out. The framework mainly changes encoding, staging, and which post-exploitation modules are available. Your Level 1 job is to notice the channel, escalate with the destination and process tree, and avoid claiming a brand unless intel or sandbox output actually names it.

Cobalt Strike, as seen in telemetry

Cobalt Strike is a commercial adversary-simulation platform whose Beacon implant is frequently abused in real intrusions. Defenders talk about Cobalt Strike because Beacon is built to blend and persist, not because you will operate a team server. Common analyst-visible themes:

• HTTPS beacons to domains that are not the company's identity provider, content delivery network, or software-update vendors—sometimes newly registered, sometimes sitting behind a popular cloud host.
• Sleep and jitter: check-ins are not a solid TCP shell; they are periodic. Packet captures and proxy logs show repeated similar HTTP requests with gaps.
• Named pipes for linking beacons over Server Message Block (SMB) inside the LAN, so some C2 never leaves the segment as HTTPS. Sysmon named-pipe events and odd pipe names become the host story.
• Malleable profiles that make HTTP look like a legitimate application's URI pattern. The giveaway is often who is speaking (wrong process, wrong user, wrong schedule), not a crude URL.

Do not memorize operator workflow. Memorize beaconing + odd HTTPS + named pipes as the Cobalt Strike-shaped picture SAL1 expects you to recognize.

Beaconing versus a reverse shell

A reverse shell is typically interactive and session-oriented: the TCP (or Transport Layer Security) connection stays up while the operator types. NetFlow or firewall connection tables show a long-lived flow, bytes in both directions, often with one process holding a socket for minutes to hours.

Beaconing is callback-oriented:

• The implant sleeps, then checks in, receives a task if one is queued, and sleeps again.
• Jitter randomizes the interval so the pattern is not a perfect metronome, but hunting still finds near-periodic destinations.
• Traffic volume per interval is often small until a task (file collection, additional payload) runs.
• The channel can look like ordinary web browsing in a coarse firewall view: short HTTPS to port 443.

Why operators prefer beacons over a raw reverse shell:

• Always-open shells are easier to spot in connection tables and Endpoint Detection and Response (EDR) network views.
• Beacons survive brief network drops and laptop sleep/resume better than a single SSH-like socket.
• Sleep makes short sandbox timers miss later stages.

Why reverse shells still appear:

• Fast hands-on control during an intrusion, especially in noisier or less mature attacks.
• Simpler tooling; Metasploit-style sessions remain common in commodity incidents.

Detection indicators you can use on an alert

Work from network, endpoint, and identity together. No single Indicator of Compromise (IoC) proves C2.

Network and proxy

• Outbound HTTPS from processes that are not browsers, updaters, or known agents (powershell.exe, cmd.exe, rundll32.exe, unsigned binaries in user-writable paths).
• Destinations that are rare in the enterprise, newly seen, or categorized as parked or newly registered.
• Regular request sizes and URIs (beaconing), or one long flow with interactive timing (reverse shell).
• TLS to an IP with no Server Name Indication (SNI) that matches a business service, or a certificate that does not match the name users think they are visiting.

Endpoint

• Unexpected listening sockets (bind-shell hypothesis) versus unexpected outbound sockets (reverse-shell or beacon hypothesis).
• Named pipes with random-looking names, or pipes connecting unusual processes (Cobalt Strike-style linking).
• Parent/child: Office or a browser spawning a scripting host that then owns the network connection.

Identity and context

• The user is in finance, but the host is beaconing at 03:00 local when nobody is on shift.
• Multiple hosts sharing one rare C2 domain (campaign), versus a single noisy lab virtual machine.

SOC triage example (detection only)

An EDR alert fires: powershell.exe on workstation WS-042 has a 47-minute outbound TLS session to a domain the company has never visited, while the user's browser is idle. Proxy logs show a PowerShell client handshake, not a browser fingerprint. This is victim-initiated—so think reverse shell or HTTPS C2, not a bind shell from the internet. You do not try to reproduce a payload. You isolate per playbook, capture the destination, hash, and process tree, and escalate with a long-lived outbound C2-like channel from a scripting host.

If instead Sysmon shows a system process talking to an internal peer over an unusual named pipe every two minutes, and there is no internet flow, consider SMB beacon linking. The internet C2 hop may live on a different host. Pivot; do not close the ticket because the workstation has "no bad IP."

Common traps

• Inbound-only thinking. Closed inbound ports do not refute reverse shells.
• Brand tunnel vision. Not every beacon is Cobalt Strike; not every TCP 4444 is Metasploit. Describe the behavior, then attach a name if intel supports it.
• HTTPS means safe. Encryption hides content; it does not hide destination, process, timing, or certificate oddities.
• C2 confused with exfiltration. C2 is control. Exfiltration is bulk data leaving. They often share a channel, but volume and payload-byte direction tell different stories.
• Trying to "test" the listener. SAL1 scores classification and evidence, not reproducing a shell.