HIDS Evasion Techniques

Greetings all,

I'm working on a theoretical text that outlines possible host-based IDS evasion tactics. I'm curious if any AO members have any comments/insights to share. Some of my current theories draw from network-based IDS evasion techniques and some are just thoughts...some subpoints may overlap into other categories but I'm not worried about that right now. I'm mostly interested in discovering what other theories may be out there.

Here's a strawman of my work-in-progress and several questions I'm currently chewing on. Ignore the titles- they're just there to keep things categorized... :)

appreciation extended in advance.

#################

Host-Based Intrustion Detection Evasion Tactics

1. 'Target Saturation'

a) overload the target HIDS w/ enough valid information that the attack sneaks by undetected.
b) overload the target HIDS w/ enough invalid information that the attack too buried in log files/alerts to be noticed
c) silence the HIDS by cutting off alerting channels (DoS mail server, etc.)

2. 'Ninja Mode'

a) trojan plant on the inside which initiates outbound connection to attacker
b) impersonation of valid traffic via mimicry/hijacking
c) 'overtime' attack...basically, attacker knowingly triggers a few alarms over a long period of time. this may cause the HIDS admin to misconfigure the HIDS, turn off alerting, or otherwise cripple it out of sheer annoyance.

3. 'Takeover'

a) disable HIDS from within after obtaining 'root' on adjacent devices
i. adjacent servers could be leveraged in attacks on HIDS
ii. adjacent switches/hubs could be configured to disable HIDS
b) use adjacent, compromised server(s) to launch 'diversionary' attack on HIDS


############

Questions:

1. is it possible to remotely enumerate a target and discover HIDS?
2. can network topology, after the recon phase, be leveraged to mask activities from HIDS?
3. can vulnerabilities in the Host OS be exploited to evade HIDS?
4. can we remotely determine through probing methodology what rules/filters/signatures the HIDS may possess?


Thanks again!

Cheers,
<0

Most of the HIDS I have come across do not rely upon looking at traffic to determine whether an attack is taking place or not. That is more the job of the NIDS. The HIDS I have come across tend to be based more on watching the filesystem itself for changes. Most make an MD5 hash for each file which is almost imposiible, (some say it is impossible), to circumvent, (it's like a fingerprint, you can't change the file without changing the MD5 hash).

Thus, IME, to answer your questions:-

1. Remote enumeration would not expose the HIDS since it could care less about network traffic and never ventures out in the "big wide world" except to page/email the admin to warn him.
2. The HIDS isn't looking at traffic - The NIDS might be though, that's the one you need to get past at this point.
3. Depends what the HIDS is watching and where you make your changes. Since the HIDS I use is configurable it's a moving target. You can guess some of the folders to avoid changing in any way such as %systemroot% and maybe %wwwroot% for example but unless you know the administrator inside out and backwards you have little idea what else he has "locked down". If you get lucky and avoid the HIDS then you could shut it down if you have elevated your privileges successfuly but if you change anything in the monitored folders then when the admin notices and restarts the HIDS your cover will be blown.
4. See 1 & 2

Point(s) well taken.

I'm eager to continue the conversation :)

I know HIDS is completely reactionary in its approach versus NIDS which 'only' examines network traffic. But what I am getting at (and curious about) is that:

1. one could probe from the network to determine what reactions match what behaviors. It isn't the traffic itself that will perturb HIDS, rather the end-target of the traffic. This requires owning more than just one host in the system; indeed, one would need to be tapped into the alerting mechanism of the HIDS (whether that be logging, remote logging, or email based).

forgetting the 'real' plausibility for a moment, theoretically i think this might be a vector to 'enumerate' HIDS.

it could also fall into 'zero-knowledge proof' arena where one could elicit responses from the HIDS and determine what it 'knows' or watches without actually having evidence of its configuration. HIDS only has two choices- react or do not react. if it reacts, one determines that HIDS 'knows' w/out configuration evidence. if HIDS does not react, one can deduce that it doesn't 'know'. Hmmm...call it mapping by proxy!

2. because HIDS is purely reactionary...if one can 'make' it react then one would possess great leverage over HIDS. This the axiom i'm basing much of my evasion tactics on and is quite different I believe from NIDS evasion (although the specific techniques may be similar). Meaning, one isn't worried about being detected as is the case w/ NIDS, rather one's concern should be centered around 'what' does the HIDS react to; does access to a specific object elicit a HIDS reaction or does only access at specific times/sources/etc. elicit the response.

If responses are reactions to specific actions (which they will be- we can assume this is true already by the nature of HIDS) one then has critical clues which can be (theoretically) employed to create 'masks' for malicious activity. This is where my thoughts about mimcry/impersonation came in to play.

3. Furthermore, b/c HIDS is reactionary, i believe one has great opportunity to take advance of 'target saturation' tactics. Under these methods, the HIDS has no choice but to react- to log, to log remotely, or to alert via email. Doesn't this present prime attack vectors? I believe it does...

4. Lastly, would you agree that whilst HIDS isn't using pattern matching on network traffic, it does use pattern matching for local activity?


All in all, I would openly concede that what I'm writing is akin to walking the Great Wall of China looking for a door to enter through. But that doesn't mean a door doesn't exist. :) And I'm more interested in this subject from a theorectical rather than pratical perspective.

Cheers,
<0

I can understand why you are interested from a theoretical standpoint but you also have to see the practicality otherwise you could wander off into any "pie-in-the-sky" scenario and really just be wasting your time.

I would suggest that your efforts to enumerate the occasions that the HIDS does "squawk" would cause a normal admin to begin a forensic investigation. You see, if you are changing files on my server, which is what will trigger my HIDS, then you already have some level of access. Most likely a level that I don't want you to have.... ;) In my book that means I've been "hacked/cracked".

If you were a domain user trying this enumeration I would start a forensic investigation that might well result in your termination.

Now, what happens if the admin choses not to be alerted actively? What happens if the HIDS reports only to the console? You may be fooled into thinking that HIDS either doesn't exist or that it won't alert on the actions you have just carried out when, in fact, it most certainly has.

IMO, HIDS is the _final_ layer of protection. You have to have already passed through the other layers undetected, (and continue to pass back and forth through them undetected). The HIDS is my "OH Sh17" defense...... Too late to prevent anything from ocurring but timely enough so I don't continue onwards in cloud-cuckoo land indefinitely.... ;)

Have to go to a meeting right now..... Be back later

I agree 100% with your defense-in-depth strategy Tiger. Unarguably, HIDS is a final layer in a DID posture and really proves its worth by providing evidence of an attack after it has occured, not during the attack as is the case with NIDS.

Furthermore, my "theory" is vastly specific in what it assumes about architecture, attack/penetration level, etc. The model is restrictive but I believe it suits a conversation based in theory. As you stated, in a practical model the wise security practioner will have implemented various enveloping layers which supplement/compliment one another. In fact, 'reality' negates much of my attack posturing!

Yet, I have to state that much of my purpose in this thread is to gain/share 'hypotheticals' that do in fact translate to pratical knowledge. Meaning, by understanding HIDS and how it may be possible to evade it, i believe our pratical knowledge will be much stronger and serve to implement better/stronger layers above HIDS.

I do very much appreciate your comments. Very insightful and helpful. Quite a good discussion...

To continue though:

Quote:

---

I would suggest that your efforts to enumerate the occasions that the HIDS does "squawk" would cause a normal admin to begin a forensic investigation. You see, if you are changing files on my server, which is what will trigger my HIDS, then you already have some level of access. Most likely a level that I don't want you to have.... In my book that means I've been "hacked/cracked".

---

I agree in a practical model. But, in our little penetration utopia...what if the HIDS is saturated w/ a large volume of 'events'? Isn't it indeed likely that sifting through any log or serialized email alert(s) will prove (in the short term?) futile? For example:

let's agree that the DoS threshold is x. The attacker doesn't want to DoS the HIDS, but wants to grab some object for espionage. So, the attacker generates a large volume of activity, which we'll call y. Here, y<x. Yet, y is greater than the amount of information that the IDS analyst/incident handler can process. Isn't it likely that the attacker will succeed in his/her goals before the analyst can determine (if at all) what the true malicious activity really was?

I think of it like this:

the enumeration is like a thief throwing a brick through a window. Does an alarm go off? If not, could it be a silent alarm? How long does it take for the cops to arrive?

the target saturation is akin to presenting so many targets for the analyst/investigator that they will be unable to determine the 'real' malicious activity.

Thoughts?

Again, i'm just trying to continue the conversation; no ill-will intended in my retort (i try to be careful when posting as 'tone' and 'intent' are often lost in the black/white) :)

Cheers,
<0

Lessthan: Don't worry about losing the intent of your posts in "black and white", I know an attempt at insult or whatever when I see one..... ;)

While DoSing a HIDS may be a valid tactic to try to hide the one important change, (to you), you still trigger the HIDS implying to even the most dense of admins that files _have_ been changed. You may flood him with so many changed files that determining which file really does the "dirty deed" is actually trivial to mitigate. It's called reformat, reinstall.

Assuming that your intent is to evade a HIDS in order to elicit information held on the server then your evasion technique must not change the drives at all. Read them all you like but make no changes and you will not set off the HIDS that bases it's alerts on the alteration, addition or deletion of files.

You might also consider, (using your brick/window/police analagy), surveying the default settings for the most common HIDS. Checking file integrity over a large number of files is extremely disk/processor intensive so most can't afford to do it in "real-time". Since, without forcing and accurately picking up on the "squawk" a HIDS makes, (which is an alert to the admin in itself), you really have no idea what HIDS may be in use... But you can still use the "brick". Assume that at the completion of your survey the minimum time is 15 minutes between file integrity checks then there is, literally, your 15 minute "window"..... ;) You can make any addition and subsequent deletion of added files in any folder on any drive regardless of the HIDS if you hit the window. Your problem is that you don't know when the next integrity check is. Probability implies that you will have a maximum of 7.5 minutes. I would suggest 2.5 minutes as your working "window" through which to lob your brick. Of course if you can compromise the machine in such a way as to not alter the drives and from there monitor the running process' CPU time then you will give yourself the whole 15 minutes if you accurately identify the process carrying out the integrity check. At that point you can add and delete the added files at will until the beginning of the new cycle. The HIDS will see nothing if you have returned the drive to it's original state by the time the cycle begins - thus you have evaded the HIDS.

Frankly, DoSing a HIDS is pretty counterproductive as the mitigation technique, while something none of us like doing is so relatively simple. Worjing your way around a HIDS is feasible and could be done in such a way as to not alert the admin - which should be your intent anyway since the first alert should put you in danger of being identified by a goos admin.

Thoughts

Thanks for understanding. :)

continuing on then...

No, I don't think DoS of a HIDS is valid, but rather counterproductive since the attack is negated when the target becomes unavailable.

But I would posit that saturating it with enough 'information' to hide malicious activity but keeping under the DoS limit is a valid evasion technique. The true malicious activity becomes a needle buried in a haystack of 'non-real' malicious activity.

Also, under my hypothetical, if all the attacker is after is a file (say, a .xls with payroll information), causing a reformat/reinstall if actually beneficial to the attacker, isn't it? I mean, there goes a substantial amount of evidence.

DoS'ing a NIDS may be a different matter though, but isn't in scope with our convesation.

Man, I really dig your explanation of the integrity check interval(s). That's an avenue I hadn't considered and have added to my notes accordingly! I'd dole out some positive antipoints but AO won't let me...spread around indeed.

Lastly, you mentioned the HIDS process loaded in memory. Hmmm...might this not be another avenue of attack? Meaning, I'm aware of tools that allow remote running process viewing/management, which could be leveraged against HIDS. Another good insight I'll explore.

This discussion has provided me with several new insights into evasion methodology and also in effective HIDS/other network security safeguard layering. I really appreciate it Tiger- thanks a ton!

Cheers,
<0

Lessthan: I mispoke in my brick/window/police analagy.......

Your window is restricted to the period from when the current integrity check ends until the next one starts. For example, if the check is set to trigger every 30 minutes and the check itself takes 25 minutes then your window is 5 minutes. You would need to monitor two full cycles to be able to determine the freqency and duration of the checks. That would give you the window. The would be accomplished by a memory based monitor that displays process CPU usage. You could go one step further and have a monitor that not only locates the process carrying out the integrity check but also which files it is opening. After the conclusion of two cycles the order in which the folders are checked would be apparent and you could expand your window size appropriately by using the early folders to pass your disk writes to, (remembering that cleanup is very important to evade detection).

Quote:

---

That would give you the window. The would be accomplished by a memory based monitor that displays process CPU usage. You could go one step further and have a monitor that not only locates the process carrying out the integrity check but also which files it is opening. After the conclusion of two cycles the order in which the folders are checked would be apparent and you could expand your window size appropriately by using the early folders to pass your disk writes to, (remembering that cleanup is very important to evade detection).

---

I was going to throw that in, but you beat me to it. ;)

It would seem that one place you can almost guarantee that the HIDS is NOT going to be watching is the temp folders. If it were, then the admin would recieve so many false positives that he'd end up shrugging off the alerts anyway. (boy cried wolf?)

Very interesting disucssion going on here.

Phish: Yes, while the discussion is somewhat theoretical in practical terms monitoring an entire drive isn't practical due to the false positives you mention. I know it's a pain with the webmaster here changing pages in the %wwwroot% folder and me seeing 46 changed to files.... It does become a "cry wolf" situation but you have to force yourself to look at the files changed to ensure that they seem resonable for normal activity and call him if it appears "odd".

Certainly HIDS is far from infallible unless it also watches the traffic from the network and analyzes that. But that put's it in the realm of a NIDS to me so it falls outside the discussion. But that's why I rate the HIDS as my "Oh Sh17" monitor..... If it "goes off" for real then I'm in trouble..... :eek:

Of course, if you manage to compromise the machine to the extent that you can monitor the HIDS activity and plan your "windows", in all practical terms, you own the box and you probably have similar rights on other boxes less likely to be running a HIDS where you can "play" to your heart's content and would be able to extract almost any information you wanted from the HIDS box without triggering the HIDS itself.

I don't have any more to add to the discussion right now. At this point, I'm ready to collate my research into more concrete categories and begin running some experiments.

I'll be sure to post back to this thread if something comes to mind. I also plan to post my paper once completed (it is due at the end of April).

Thanks again everyone.

Cheers,
<0

PS- I do have one last comment!

We install HIDS on 'high value' machines to give us that last/extra layer of defense. The 'oh shi7' as Tiger Shark put it. Does this effectivly label the machine as "Beware of Dog" or as "Eat at Joes"...?

Just a little philosophical food for thought to end on i guess :)

Lessthan:

Quote:

---

Does this effectivly label the machine as "Beware of Dog" or as "Eat at Joes"...?

---

bearing in mind that traditional HIDS do their work internally to the machine the ability to detect them without triggering them is severely hampered. In fact, in practical terms, anything that advertized the HIDS would be counter-productive... All you would be doing is telling your attacker which machines to avoid.

So, in terms of your question I would suggest that a HIDS is more akin to the dog that is trained not to bark and to attack you from the rear when you enter the premises.... ;)