SonicOS 7.0 Rules and Policies for Classic Mode

Reverse Shell Exploit Prevention

The reverse shell exploit is an attack that you can prevent by using the App Rules custom signature capability (see Custom Signature). A reverse shell exploit could be used by an attacker if he or she is successful in gaining access to your system by means of a Zero-day exploit. A Zero-day exploit refers to an attack whose signature is not yet recognized by security software.

In an early stage while still unknown, malicious payloads can pass through the first line of defense which is the IPS and Gateway Anti-Virus (GAV) running at the Internet gateway, and even the second line of defense represented by the host-based Anti-Virus software, allowing arbitrary code execution on the target system.

In many cases, the executed code contains the minimal amount of instructions needed for the attacker to remotely obtain a command prompt window (with the privileges of the exploited service or logged on user) and proceed with the penetration from there.

As a common means to circumvent NAT/firewall issues, which might prevent their ability to actively connect to an exploited system, attackers make the vulnerable system execute a reverse shell. In a reverse shell, the connection is initiated by the target host to the attacker address, using well-known TCP/UDP ports for better avoidance of strict outbound policies.

This use case is applicable to environments hosting Windows systems and intercepts unencrypted connections over all TCP/UDP ports.

Networks using unencrypted Telnet service must configure policies that exclude those servers’ IP addresses.

While this use case refers to the specific case of reverse shell payloads (outbound connections), it is more secure to configure the policy to be effective also for inbound connections. This protects against a case where the executed payload spawns a listening shell onto the vulnerable host and the attacker connects to that service across misconfigured firewalls.

The actual configuration requires the following

  • Generating the actual network activity to be fingerprinted, using the netcat tool
  • Capturing the activity and exporting the payload to a text file, using the Wireshark tool
  • Creating a match object with a string that is reasonably specific and unique enough to avoid false positives
  • Defining a policy with the action to take when a payload containing the object is parsed (the default Reset/Drop is used here)

Was This Article Helpful?

Help us to improve our support portal

Techdocs Article Helpful form

  • Hidden
  • Hidden

Techdocs Article NOT Helpful form

  • Still can't find what you're looking for? Try our knowledge base or ask our community for more help.
  • Hidden
  • Hidden