0

Suppose this scenario:

You are already inside a corporate network. Suppose to find out a RCE in a X service. The machine that hosts that service is behind a network-based firewall, ingress rules and IPS/IDS are not a problem. You don't need to reach the internet, just your machine inside the network, on the other part of that firewall. You have ready a small malware which will grant you a reverse shell when executed, with IP-Port hardcoded.

In that case, what would you do to avoid detection?

  1. upload the malware to the target ( for example running a curl command via RCE ) and execute it, hoping that the egress rules of the firewall will not cause any trouble with the port hardcoded?

  2. upload first a small program which will test egress rules ( for example the first 2000 ports TCP/UDP, 1 port each 5 secs ), and then upload the malware after compiling it based on the output of the test? And what about a blind RCE? How would you read the output in that case? Would be preferable add this code ( the port scan ) to the malware?

Any other idea is more than welcome!

hyogy
  • 3
  • 4

1 Answers1

0

Uploading 2 things doubles your chance of the uploads being detected.

"Blind RCE" should not be an issue. You will know if the connection is made, when a connection is made ... You do not need to read the console on the target-side.

You want your efforts to take a few steps as possible to be successful in order to evade detection. If you need to prepare for experimenting in the field in order to be successful, then you need to design your approach to take an optimal number of steps to find success.

To that end, it is better to include a simple "port test" in the payload to test the common or expected allowed ports first, then test an increasingly wider field of ports. When a connection is made, it can stop searching. These tests can also be throttled to happen over time and not in a blast, but not so slow that you are detected and blocked before you can make a connection.

This is why "information gathering" stages are so important. You want to eliminate as many of the guesses you need to make. You have not provided any details about the target that would help you or us to reduce the number of guesses, so the recommendation is to gather as much information as possible in a "safe-to-fail" way, then keep your steps to a minimum when you are in an "unsafe-to-fail" stage.

schroeder
  • 123,438
  • 55
  • 284
  • 319
  • I did not provide more details because its just a doubt I came up while studying, this is not based on a real scenario. OFC in a blast is like firing fireworks, and as you say, too slow also could be a problem, so how could I understand with the information gathering the perfect timing for each connection? – hyogy Aug 12 '21 at 10:13
  • Speaking of detection, the malware also splits the output of the commands in small packets, to make less suspicious traffic network, but I know that some IPS/IDS may give an alert if a packet is too small ( for example, the packets size it sends are between 30 - 40 bytes ). Are they too small? – hyogy Aug 12 '21 at 10:28
  • Don't think "perfect" think "optimal". You might want to know how often the logs are checked, if there is a SIEM, if the firewall is a next-gen firewall and adaptive to anomalies, etc. – schroeder Aug 12 '21 at 10:29
  • "too small" can only be determined by the specifics of the protections in place. Knowing the name and type of protections, you can look up its documentation or get a version for yourself and test at home (definitely "safe-to-fail") – schroeder Aug 12 '21 at 10:30