Introduction
In Red Teaming, it is essential to keep your tactical, mechanical skills, and operational competence updated with researches and drills. For operational competence against endpoint security solutions, we regularly research bypass methods, and separately combine our findings with tactical abilities like hiding and to operate undetected in our AD lab drills.
In our last research, we have bypassed FireEye EDR and get a meterpreter shell, also found a possible vulnerability. You can read it from here: https://cyberstruggle.org/fireeye-edr-bypassed-with-basic-process-injection/
This time our team decided to publish writing about another popular security solution, Symantec Endpoint Protection (SEP).
We have installed SEP on a Windows 10 17763 operating system and wrote aggressive custom policies for high detection.
Unlike most, our team generally prefers “Bring Your Own Land” over “Living off the Land” in our red team engagements. So, we decided to continue this bypass drill with process injection. which is the same method we applied in FireEye EDR bypass previously. Initially, the main goal was a basic calculator popup by fuzzing the SEP. However, we got an interesting false positive detection. SEP classified this executable as “meterpreter” before execution.
This detection was a signature-based one because we did not execute our binary. We thought that maybe SEP classifies all kinds of process injection signatures as “meterpreter”, but then it is realized that this would be too risky for SEP and can also affect a lot of critical processes negatively.
To get over this problem, we tried to add some random loops and math functions inside our code to change the hash value and maybe to confuse the SEP, but again SEP classified our executable as a malicious one.
Afterward, we erased the calculator shellcode inside the byte array and tried the same executable. At this time it was not detected. Either all kinds of static shellcodes inside the code were getting detected, or SEP classifies calculator shellcode as meterpreter shellcode.
So we can call our functions, but we cannot store shellcode inside our binary. From this perspective, we decided to download our shellcode from the internet in runtime and inject it afterward.
In order to do this, we wrote calc.exe shellcode in hex format inside a file and published it with a web server.
Inside our code, we downloaded the hex formatted shellcode string and converted it to a byte array with a custom function.
This shellcode can also be transmitted with various channels, but the purpose of this drill was to bypass only, we will publish writing about it later.
When we executed the binary, a calculator popped up.
Now we can download shellcode from the internet and inject it inside our system. This is what we call, “Bring Your Own Land.”
Then, we tried to inject the raw output of below command into the binary by downloading it from remote.
“msfvenom -p windows/x64/meterpreter/reverse_https”
However, when we ran the executable, it was detected by the “Intrusion Prevention” module (kind of an endpoint IPS) and classified as reverse_https attack.
This detection was about network traffic, but we were using encrypted https traffic, which is not readable. There should be an anomaly inside the reverse_https network traffic which helps IPS module to identify it.
To get better insigth about the reason of blocked traffic by IPS module, we started to analyze the traffic itself. Inside the traffic;
- The target sends us a “ Client Hello” packet and starts the SSL key exchange (this also shows that our shellcode runs as expected).
- Our listener sends the public SSL key, and the target immediately closes the TCP connection with the FIN packet.
This immediate connection cut indicates that SEP is detecting the msfconsole’s public SSL key, and it is the point where we understand the need of using custom created SSL.
Impersonate_ssl is a msf module that creates custom impersonated SSL keys. We used this module to create a SSL and copied amazon.com’s SSL properties and created a payload with this custom SSL.
Creating new payload:
We also configured our listener to use and verify this SSL during the connection. When we downloaded and executed our ready to use binary, we recieved a meterpreter shell.
Since the main goal was only bypassing the SEP, we were still having a strong curiosity to understand what will happen if we try to pivot to the internal network.
The question is: Could SEP detect pivoting processes?
We looked at the NAT IP of the target machine and added a route to the NAT network, then scanned port 445 of 192.168.96.1 (our main windows machine) and got a proper answer.
To be sure that our pivoting was successful, we listened to the network traffic of the NAT network and confirmed that requests are coming from the pivot point; which indicates that we had successfully transmitted the network traffic over the compromised host by using pivoting.
Notes:
- EDR is not a magic. An attacker might easily bypass it and pivot inside the network.
- Even if the EDR does not detect this kind of executable files, it was still too easy to analyze and detect it by an analyst, but we will handle this topic with another document about red teaming.
