CSA trojaner rule not working as supposed to (with part of EPO client)

[aduerr]

Hi,

I got a problem with a part of the McAfee EPO client (McScript_In_use.exe) which tries scheduled automatic downloads and starting these.

I made an exception to the preventing trojaner detection rule which now should allow this application this behaviour (downloading and invoking executable files).

Although I made this exception, every hour when this exe triggers a scheduled update I get an event that would prevent this action(using IDS mode for profiling). The event states that it would be excactly prevented by my customized trojaner rule!

I changed the application class to which this exe belongs to allow all it`s descendents and not only this process but it didn't solve the problem.

After that I disabled every trojaner rule in the belonging group except one default trojaner rule and made one whole new exception with the wizard but that didn't help either. I also accept all wizard suggestions and let it built a new application class(absolute path to the exe).

Although everything seems to be correctly customized my trojaner exception does not allow this action to happen.

Any ideas would be greatly appreciated!

Regards,

Arne

[aduerr]

I came across this thread concerning this issue:

http://forum.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Security&topic=Intrusion%20Prevention%20Systems/IDS&CommCmd=MB%3Fcmd%3Ddisplay_location%26location%3D.1dd71c9b

I`ll try out that.

[tsteger1]

You could try adding the Virus scanner applications app class to your trojan detection rule. I didn't try that before I posted in that other thread but I think that would cover it too.

Tom

[aduerr]

Thank you Tom! I`ll try out that one too and let you know what workaround fixed it when I cracked this one :)

Definitely something which CSA development should look into.

Regards,

Arne

[aduerr]

Hi,

yesterday I tried using both methods (adding Virus Scanner Module to TD exception too and giving McScript_inUse.exe full file access and application start control) but none solved the issue.

Regards,

Arne

[mcvosi]

This was sent to me by a TAC engineer. It helped me to fix my issue with, in this case, Trend Micro OfficeScan.

---

If you see a message similar to this (the actual downloaded executable may be different in your case):

The program 'C:\Program Files\CA\Common\ScanEngine\Incoming\iv_nt86.exe' was recently downloaded and attempted to execute. The user was queried whether to allow this operation. The user chose 'Terminate (as default)'

and you want to exclude the application that did the downloading from the Trojan Detection Rule, there are some steps you must do.

The exclusion in the Trojan Detection rule is for the application that actually did the downloading - NOT the actual downloaded file. The message says that iv_nt86.exe was recently downloaded. Therefore, the file that was downloaded is iv_nt86.exe. We do not know what actually did the downloading in this instance most likely because the process was terminated before we could find out. To find out which application did the downloading, set up a File Monitor Rule where the application class is "all applications" that attempt to "read and write" the file "iv_nt86.exe" (no quotes around these values). Then once this file is accessed, you will see in the event log which application is doing the downloading of the file. Then exclude that application that downloaded iv_nt86.exe in the Trojan Detection Rule.

[tsteger1]

The McScript_inUse.exe is the file doing the downloading in this case but excluding it or all .exe's in the folder doesn't seem to work for him.

I ran a profiler job and created a File Monitor rule and it's just .exe's in the **\Network Associates\** doing the talking.

Strange...

Maybe try a new test group and/or policy for this host and try again. You may also want to take it out of IDS mode.

Can you paste the message text here?

[aduerr]

Hi everybody,

I want to share my experiences on this issue:

problem: a part of the EPO client called McScript_InUse.exe gets triggered to download "something". The trigger is a scheduled event (every 3 hours) and/or happens once on rebooting a system.

normal workaround: create an exception via wizard and be happy.

result: the trojan detection exception rule which I created doesn't work as supposed to. Still getting events stating that this behaviour is still not permitted by the customized trojan detection rule.

In the meantime my trials were unsuccesful to eleminate/permit this event.

As mentioned at the end of the other existing forum thread a tac workaround exists for this behaviour. Thanks to Mr. Clevenger I received this workaround doc and had a little time to study and check it out yesterday.

little bit off-topic: in advance to mentioned workaround there my issue is a little bit different. The TAC document is written about a manually/user triggered Auto Update function.

In opposite to this my problem persists with the system scheduled events.

Yesterday I tried the mentioned procedures by TAC. These rules didn't solve my issue.

For a temporal solution I created two app-classes, one dynamic and one static on McScript.

Now I configured two application builder rules for all applications which either try file access r/w or startup on McScript_InUse.exe to put them into dynamic McScript Class.

After that I created two application control rules in which I once allowed the dynamic McScript class attempt to run all applications and once that all applications are able to run the static McScript class.

Now I added both McScript classes to the TD exception(download and invoking executable files).

result: I get no more events on these scheduled updates but still once on system rebooting.

to-do: for breaking it further down I have to use file monitor access rules to precise my rules.

I used logging checkbox to verify hit counts on my application control allow rules which confirmed that these rules are indeed necessary.

These McScript is driving me nuts ;)