Pluralsight blog Where devs, IT admins & creative pros go for news, tips, videos and more.
Supercharge your skills with expert-authored tech & creative training. Unlimited. Online. Get it now →
November 15, 2012

Ethical Hacking: How to Avoid Intrusion Detection Systems


Watch these Ethical Hacking videos, and you’ll understand skills like wireless network security, social engineering, hijacking, and more. With these tactics of ethical hacking you’ll learn security techniques through the mind of an attacker.


So, now that you’ve taken a look at getting rid of evidence on attack systems, like Windows XP, intrusion detection systems are certainly next up. Intrusion detection systems are designed, pretty much from the outset, to watch for bad behavior, and then scream and yell as loud as they possibly can the moment an attack occurs. If it’s screaming and yelling from the moment an attack occurs, and you set it off, you’re probably going to bring down administrative scrutiny. You do not want to do this. Therefore, rather than worrying about covering tracks on intrusion detection systems, the best approach is simply to avoid them entirely.

While it may sound nearly impossible because they’re designed to look for what you’re probably doing you can avoid these detection systems by watching for patterns such as large amounts of bandwidth being consumed, certain packets like ping of death and sin flood attacks. Intrusion detection systems are, actually, relatively easy to avoid setting off because they have a threshold for watching for bad things that are happening. As long as you remain under that threshold, you’re fine. If your attack begins from inside the network, typically, intrusion detection systems will not start clamoring for attention.

Tips and Tricks

For intrusion detection system avoidance, it’s actually, pretty straight forward. Keep your attack quiet. Ensure that if you’re going to perform some kind of denial of service attack, some kind of really obvious bandwidth consuming attack of any type, or syn flood that’s visible on the network, keep it for towards the end.

Do not have that be one of your first attacks. It’s a bad thing because you don’t want to spoil the entire approach at the very beginning. If you have to set off bells, make sure you set them off at the very end of the attack when there are no other opportunities.


Firewalls are another one of those nasty bits that we want to avoid as much as possible because they are designed to report logs of suspicious activity. They capture all of the traffic and information and retain it. They’re designed to be resistant to these kinds of attacks, and, if they’re not resistant, they’re designed to preserve evidence.

Similar to an intrusion detection system, avoiding leaving any kind of evidence is certainly the best way to continue your attack and not set off any alarms or leave any evidence.

Attacking Through a VPN Tunnel

Attacking through a VPN tunnel is a common technique for avoiding firewalls, because, if you’re going through a VPN tunnel the firewall probably can’t look at what’s going on in there. It probably doesn’t see the attack; the attack is simply passing through it in a transparent way. The VPN can’t be examined closely, so the firewall can’t see what’s going on.

That does depend pretty heavily on what kind of firewall and where the VPN terminates, but, by and large, the general practice is: attacking through a VPN tunnel is going to be safer than attacking a firewall itself or trying to attack through a firewall without some kind of tunnel.

Going around the firewall is, typically much better. Whether it’s physically attacking the network by connecting to it, getting on wireless and attacking the network that way from behind the firewall, or attacking a host in another way and having the host carry the attack around the firewall or beyond the firewall are typically the most effective solutions.

Bastion Hosts

Instead of worrying about setting off the firewall alarm or leaving evidence, you’re simply not touching the firewall. You’re avoiding it entirely. Another option is attacking a safe DMZ host or a bastion host. Bastion hosts usually are really hardened against our attacks so they’re harder to compromise.

Because they’re harder to compromise, and because they’re actually defended, many administrators make a hole for them in the firewall. They do not consider anything from a bastion host, or a DMZ host, to actually be a threat because they consider that that system cannot be compromised.

If you can compromise it, it’s almost a safe harbor into the rest of the network without being detected.


The rule of thumb for honeypots is to stay away from them. They are the absolute worst to run into. If you see a system on the network that says “whack whack,” the system name is “whack whack, secrets are here” or “whack whack, private content, do not disturb” or “whack whack, executive server,” stay away from those really tempting honeypots.

The moment you touch them they’re going to start screaming and yelling. They’re probably going to do it in a way that you can’t tell. They’re probably going to alert administrators, but instead of shutting down your attack, they’re going to continue to give you tempting stuff while the administrators look for the source of the attack, identify the network path, determine your source, and, potentially, catch you red handed. These are the absolute opposite of what you want to run into.

If it’s too good to be true, it probably is not true. Stay away from honeypots at all costs. Again, leave them to the very end if you know that you have to touch them, or if you can’t quite tell, because they’re tempting but not too tempting. Do not attack them early on or, have someone else attack them for you.

Look For Traffic Patterns

Another way to avoid honeypots would be to look for traffic patterns. Look for other users, legitimate users that are actually using the network properly. For example, in the “whack whack, executive server” scenario, if you have a server out there called “whack whack, executive server,” but you notice that when you compromise executive accounts and systems, none of them actually access that server, that’s probably a honeypot.

It’s almost by definition intended to be used by these executives called “executive server” but they’re not touching it. They probably know something you don’t, which is not to touch that server because it’s an alarm system.

Log Collection Systems

Log collection systems, as I said earlier, are designed in two ways. They’re designed to collect events, system logs, security logs, administrative logs and maintenance logs, and roll those all up and generate reports, or sometimes alerts.

They’re not always for security. They’re not usually used as intrusion detection or prevention systems, or even as honeypots, (they can be used that way, and I have seen them used that way), but they’re typically for normal administration, network control and management.

Because they’re usually used for normal network control and only used for security as, kind of, an afterthought, they’re usually pretty easy to compromise.

These are typically run on commodity server operating systems like Windows Server 2008 and Windows Server 2003, which means you can typically use authorized credentials. You can use either a network administrator, domain administrator, or, in many cases, even just a regular domain user, to connect up to these and actually empty out the logs.

The techniques for that are pretty similar to the ones that you saw for Windows XP, except just extending that to the server and collection service.

It will depend pretty heavily on which service is being used to collect the logs. So the actual steps will vary but the overall idea is to remember that if there is a log collection system in place you’ll be able to connect up to it and purge it out because it is not designed to be highly secure. It will be a one way trap for evidence.

About the Author

has worked in the IT field for more than 20 years. He is an award-winning author, public speaker, and instructor on a variety of technology topics including security, virtualization, cloud computing, wireless and wired networking, and IT lifecycle processes. His operations experience includes managing the Xbox LIVE operations team, the largest cloud computing operations team in the world, and consulting on operations efficiency with countless clients around the world. Mike has published several books (including two for O’Reilly) and numerous papers. He is a frequent conference speaker and classroom instructor on IT operations, computer security, and technology frameworks. Mike holds a number of certifications and accreditations including Certified Information Systems Security Professional (CISSP) practitioner and instructor.

Author's Website: