Reduce Noise when Penetration Testing

Question

Recently I participated in a capture the flag competition which was attached with SOC analysis teams monitoring our traffic.

There we were told that many tools were very noisy. Eg Sqlmap which has its full header.

As all of us were new so we weren't able to have the understanding besides doing nmap -sS scans. What else could be less noisy in the process of penetration testing? Or to be more specific what tools and approaches should be preferred to achieve this goal of being least detectable.

Answer 1

You want to increase signal and reduce noise during a pen test?

Great! Here are some things to ponder on:

1. For answers to the questions you have -- are they already answered somewhere else? For example, does Nmap data from a previous pen test provide an accurate-enough view of the data you would expect today? Would csrecon or similar provide that data? If you are on the local network, does ARP provide it? Can you speed up the ARP discovery (netdiscover, arp-scan, arping, etc) and packet-capture/MITM (e.g., bettercap) techniques or combine them with Nmap via xerosploit?
2. Can you scan from a trusted or third-party source and note the results before you start your own scan from your own infrastructure? Would scanless or similar provide that perspective? How about using the ipidseq NSE script to pivot towards idlescanning? Or how about using dnmap from tons of sources?
3. Can you modify Nmap so that it isn't picked up by IDS or blocked by IPS? Can you use a tool such as sniffjoke with a prepared configuration? How about using a different means of scanning that appears more-normal and more-TCP friendly/efficient, such as pbscan? Can you perform both Nmap and MetaSploit simultaneously with metasploitHelper?

If you already have creds, then go poking around with SPN scanning before IP/ICMP/TCP/UDP scanning. Then pivot with tools such as portia, autoDANE, and CrackMapExec.

Sometimes, other protocols are in-use on the network, such as DCE-RPC over Ethernet (as opposed to TCP/IP over Ethernet), but you could build a bridge between the two using Piper or similar. Want to create a backchannel (e.g., C2, covert channel) over ARP? Then test out slarpd/slarpc.

Other times you can create a covert channel in existing protocols, such as by using the phcct tool for TCP/IP protocol hopping or even the Forkitor method over SSH. Hide in plain sight!

How about IPv6? Is it enabled on the network but the blue team isn't looking for it? If you want to see if IPv6 is enabled, grab a local stack and use ip -6 neighbor show, ndp -an, to passively show those networks, or even actively with ping6, e.g., ping6 -c 2 ff02::1 or ping6 -a ag, ping6 -a al, ping6 -N. Run this module from the metasploit-framework -- auxiliary/scanner/discovery/ipv6_neighbor_router_advertisement

Try these techniques -- https://www.ernw.de/download/newsletter/ERNW_Newsletter_45_PenTesting_Tools_that_Support_IPv6_v.1.1_en.pdf -- to build a bridge between your IPv4 tools and the target IPv6 networks.

Answer 2

You have to make a choice: are you going for stealth, or for broad coverage and efficiency? Essentially all scanning tools, including nmap -sS, are easily detected by a competent SOC if run at a decent speed. If you want to avoid detection, you must either make fewer requests, or make them more slowly.

Have you tried running tools like Snort, Bro, or Security Onion while performing a penetration test in a lab? What signals are fired immediately? How do these tools work? If you want to avoid detection, you have to know how detection works.

If stealth is your goal:

1. Avoid obvious tools (like SQLMap) or ensure they have settings to hide things like a User-Agent string. (e.g., sqlmap --user-agent=Benign/1.0)
2. Go slowly and as targeted as possible. Know your target before you try to hit it. Surgical precision is better than brute force if you need ot be quiet.
3. If you get a foothold, pivot your traffic through there to obscure the source.
4. If you get multiple footholds, spread your traffic across multiple sources.

Answer 3

Without going too much into specifics (as they're very dependent on the circumstances of the test), you could think about things like this.

How do SOCs find attackers? Well there's a couple of ways, they might look for the signatures of known attack tools, so for example most IDSs will have a signature for nmap scanning, and if you scan using nmap you'll set that off.

Another way that the blue team could work is that they look for anomolies. So for example if they know that there's no service on the network using Port 23455/TCP and suddenly they start seeing traffic on that port, it's easy to use that as an alertable event.

So from the attacker perspective, how do you avoid that?

Well for the first one, avoid using well known tools in their default configurations. Instead of nmap try using things like operating system tools that let you connect to services (so for example an SSH client in a loop looking for SSH servers)

Also make use of techniques that are passive. Packet sniffing might reveal systems broadcasting traffic which gives away what services they are running. So for example, a Windows server may make certain broadcasts that you can pick up. so then you know what it is and you can directly contact it on the common Windows ports, which likely won't show up on a SOC dashboard as that's pretty normal traffic.

The other thing to avoid is common default ports for attack tools. If the tool ships with a default, use something else and preferrably something which is already in use on the network, like using 443/TCP for SSL traffic, that'll blend in quite well, in all likelihood.

Answer 4

Regarding Nmap, there are number of options worth reading straight from the manual, that can help you conduct stealthier scans: Nmap: Firewall/IDS Evasion and Spoofing