Choose Your Own Red Team Adventure: Egress IP
This is a continuation of a Choose Your Own Red Team Adventure series. If you don’t know how you got here, start at the beginning. Otherwise, continue reading …
You are a careful and considerate Red Teamer; that and you certainly don’t want to experience the business end of the Computer Fraud and Abuse Act (CFAA) or expose your employer up to legal liability. So, you try to carefully balance the objectives of looking like a real threat actor as well as ensure your malware doesn’t run on the wrong computer.
You have a process you always follow. You send non-malicious emails from infrastructure that you never reuse in any sort of malicious way to email addresses of employees that you harvested using OSINT techniques. These emails look like quality marketing emails for a company that you’ve maybe heard of before (but you actually haven’t). They’re not super memorable. They get forgotten by their recipients. In other words, they’re perfectly suited for their job.
As recipients start to receive the emails, their devices render the HTML which includes fetching images from the infrastructure you control. All you care about is in the logs of those requests: the user agent strings and IP addresses that hit your infrastructure. Each victim received a slightly different email with trackers in the image, just like a marketing firm might use. Now you know exactly which user agent and external IP address belongs to each of your recipients. From there, you can quickly analyze that most of the mobile devices are likely from random mobile IP addresses — you don’t care about those in this case. The user agents indicating full endpoint devices tend to cluster around 2 different IP addresses, each of which appear in one of two major cities, just where your OSINT suggested their offices would reside.
As you prepared your weaponized phish from different infrastructure you setup a rule on your C2 web server to only pass requests from those 2 IP addresses. Any other IP address will receive a 404 not found response and be unable to talk to your C2 server. This subtle configuration will ensure that any errant landing payloads won’t result in full access. Coincidentally, later in the campaign when an incident responder begins to reverse your malware, they also won’t be able to communicate with your C2 server from their sandboxes.
Now it’s time to find out what’s running on this host. How do you do it?
Run the tasklist, reg, and net commands
