Is This Possible or Just a Rant?

I am curious, I am came across a thread on another forum that sounded a little outlandish to me. Here it is...

Honestly my first impression was this reads like a script kiddy but just curious if I could get some 2nd opinions. Is what described above theoretical possible?

If so I am feeling a lot more paranoid.

 

Can't comment about 'how they got into Microsoft', but yes, of course it's possible to fool AV scanners by changing the file in ways such as compression.

They use various checksumming and signature techniques to spot viruses, so if the code doesn't exactly match the strain the AV vendor has seen, the scanner cannot tell for sure it is a virus. (Heuristics might be able to make a good guess sometimes, though.)

If a program is altered using software like an EXE file compressor such as UPX, the resulting code looks completely different to the original, and an AV scanner wouldn't be able to detect the file was malicious without going to the lengths of simulating the code and seeing if any viruses get decoded by it, which is completely impractical.

Anti-virus scanners cannot make you 100% safe against malicious code and they shouldn't claim to; they can only act against widely-distributed threats. If someone tailors a specific threat for you, such as a modified or compressed virus, an AV can't protect you from it, because they simply won't have seen that code before.

--
Andrew Clover
mailto:and@doxdesk.com
http://www.doxdesk.com/

 

while anything is theoretically possible, I think you should consider the fact that tehre are plenty of people attacking the internet as a whole in the past year (at least, I'm bad one news subjects) and the intent is reall malicious; clog up the internet as a whole. If someone was getting virus/trojan anywhere and everywhere without detection like this person is saying I think we would all be shut down by now.

 

This is an excellent time to once again mention using a "layered-approach" to security.......as Andrew has mention.......an is so often mentioned by others...anti-virus software protects from what it knows to protect from....an alittle bit more.........new threats evold.......an its best not to wait until the vendor updates.......other means of protection should be used as well.........that "other' means can enlist several programs from script detectors to file protectors.....
nor should it be forgot that first the virus has to get into the os.........safe habits can prevent that extensively
often times imo people are looking at the complicated when the simple is still the best.

 

I want to make it clear that I am not expecting my AV app (AVP has a strong record of detecting trojans and worms) to detect all viruses, trojans, and worms or for TDS-3 to catch all trojans, etc. But I didn't expect that a known bug could be made undetectable so easily. Keep in mind my experience with programming ending the mid 80s with Basic. But chalk it up to my ignorance but I assumed that these other bugs were unique or custom made by folks that had an higher level of programming knowledge. Not some run of the mill IT employee that has just modified a well known bug!

In the case above, Sub7 uses a well known port and wouldn't get out even if it was compressed or had a signature. But a trojan designed to tunnel out of IE would get out of most protected systems or at least that is what my conclusion is after having used several leak tests.

I will admit currently I am running a FW, AV, and a trojan detector. I have been playing with adding WG and Safety Monitor to my system, and looking other possible security layers such as a proxy like function such as Proxomitron.

My game plan would looks like this:

Inner to outer
1. Safety Monitor at the file and registry level
2. Worm Guard, AV, and TDS-3 for scanning and active monitoring
3. Upgrade FW to firewall/router (spare system resources) and use Kerio for outbound protection which is lighter on resources for inbound but more so to prevent outbound traffic
4. Proxy like app such as Proxomitron to prevent IE leaks on FW

Any other ideas?

 

Thank you for a very good posting

one more thing to add would be registry protector app, I run "regprot" at start up. Sure it won´t protect much, but if something failures, there is something more protecting for further damages.

*Ari*

 

Very good point Mr Krusty.....such a practice/program could save some alot of grief.

****************


imo its not so much a matter of training as just plain being curious that produces some of the mischief.
an while most anti virus/trojan scanners are very good if not at least decent at protecting/detecting... bypassing detection may not be nearly as difficult/complicate as many think.......depending on the intended goal. This I would leave to the experts to discuss......its not within my scope of knowledge.
what is fairly commonly known is that firewalls can be bypassed. an if the firewall is expected to help protect the os should we not offer some protection to the firewall?
the answers really are known..but these days the questions don't appear as often......

 

Thanks for the reply. Yes, that was the purpose of System Safety Monitor. It is supposed to protect the registry and act as an application firewall below the OS level. I am also familar with File Protector (have a copy haven't used it yet). Is this what you are talking about or is there level of registry protection beyond what I am mentioning here?

 

This is why you need TDS, 2 words for those trying to bypass AV scanners. Memory scanning !

Not many users modify trojans, those who do only make small changes to get past the most common AV scanners - which only use file scanning to detect trojans. To get a trojan like SubSeven past TDS-3 you would need to modify most of the trojan, which would take longer than writing a new one

 

Ahhmm! Thanks for the product indorcement Actually as per my earlier messages, I am using TDS-3, not religious, but that has changed. As well, I have been using AVP which has, to my knowledge, the strongest AV app record for detecting trojans.

Good to hear that TDS-3 offers that strong of detection against a modified bug.

 

Hi Luthorcrow,

You have really good protection with that combination

 

This is a good time again to mention either imaging your hard drive or
something I have always liked much better,,,
Flash BIOS
FDISK
FORMAT

no virus can get through this line of defense.
For the home user: FFF

for the business: Image HD recommended

 

Gavin

Memory scanning......which I use almost as much as I use butter on toast......an I lovr toast..lol

if I may please impose a question for your response....specifically the question is for my own personal knowledge growth....an not in relation to any product....

agreed of course on the use of memory scanning....question is....if the program doing the scanning is not allowed to start up at boot......FE: a trogan arrives that contains the necessary changes....but the changes don't take effect until after the computer is shut down and re-booted......in the process of re-booting the changes take effect that prevents a chosen program or assortment of programs from starting at start up..so the program doing the scanning never is started.....it could be started manually LATER if the user notices that the program isn't ON.......however, during the time the program is disabled....what then?
since the lil trojan is ever so small and fast it loads much quicker than the bulky old firewall..anti virus/trojan scanner..
there may be scanning programs that scan memory on start up.....yet there are many that don't. Plus those mentioned changes are not illegal....the registry has had legal changes made...IF the scanning program was enabled...it may notice the changes possibly.....the scanning program is not however loaded......
so......in your respected opinion.....would you suggest the use of a program that prevents CHANGES MADE AT SHUT DOWN

 

Tricky question to answer.. if the trojan is killing antivirus, antitrojan and firewall software then many of these can easily be tricked by renaming your app EXE's - rename TDS-3.EXE to something else, as the trojan searches for running known EXE's..

If a trojan is doing this it may as well do it as soon as it runs, which is what they do. So I'm not sure about the question - it could be helpful to know if something has written to the registry while Windows is shutting down

 

Gavin

Realizing how busy you must be....I thank you for taking of your time to reply....appreciated.
this is an issue that I have long wondered about. Of course the trojan would still need to enter the os before it could do its deed....then bypass the memory scans..etc
sure hope nothing like this ever developes

 

See this related thread at dslreports: http://www.dslreports.com/forum/remark,6023085~root=security,1~mode=flat

KAV and McAfee have strong unpackers; most other AVs do not. So it is possible to fool the manual file scan; however I'm wondering whether the resident auto-protect scan can be so easily fooled: since malware must still unpack in order to execute in memory, right? Cannot the resident portion of an AV scanner still detect the malware as it tries to execute?

And isn't this the principle used by TDS Execution Protection, or even my app, TrojanHunter Guard? Detect the process signature of the malware as it tries to execute in memory?

Isn't it impossible to alter the actual process signature (not the file signature) without completely rewriting the malware and changing it into something else? If you altered the process being run in memory, it would no longer be "SubSeven" or "Opaserv", but a completely different trojan or worm, right?

I applaud KAV and McAfee for having strong unpackers, and I have urged my company (Symantec) to follow suit and strengthen NAV's currently weak unpacker: but I still think NAV Auto-Protect (or NOD's AMON) should be able to protect against execution of modified malware, even if it misses the file because it is packed or encrypted differently from the signature in its database.

This does point out limitations of signature-based scanning, but I'm skeptical about how easy it is to actually change the signature of a running process in memory, without completely rewriting the malware, as Gavin suggested.

 

Randy, ok you wanted an essay, you got one

> KAV and McAfee have strong unpackers; most other AVs do not.
> So it is possible to fool the manual file scan
To an extent - it makes detecting the original file harder as it has to be unpacked, but detection of the packer itself is usually very easy - just look at the code at the entrypoint, it will be the unpacker.

> however I'm wondering whether the resident auto-protect scan
> can be so easily fooled: since malware must still unpack in
> order to execute in memory, right?
Correct. Attempting to execute packed data will almost certainly result in a GPF or other memory-related error. For a trojan, virus, or anything to run, it must run unpacked/unencrypted. In the case of packers this is usually done straight away - the unpacker unpacks the compressed program and then jumps to the original entry point (OEP), where the program runs normally, but there can be exceptions to this rule.

> Cannot the resident portion of an AV scanner still detect
> the malware as it tries to execute?
Usually, because when it's running it's unpacked. However, when the process first loads into memory, it is still packed - it isn't until the unpack part of the program has finished running that a 'snapshot' can be taken of the unpacked process to analyse the unpacked code.

The unpack engine we've already developed for TDS4 (which currently successfully unpacks all ASPack, Petite, UPX and various other packers) essentially allows the unpacker part to run up to the point where it hands over control to the OEP, at which time a snapshot can be taken of the unpacked code. The unpacked code is never executed.

However, remember that there's nothing stopping a malicious program from decrypting parts of itself and executing them before re-encrypting them, so the unpacked/decrypted code may only exist for a split second. If the function isnt required again, the program may even overwrite the function code with random data.

> And isn't this the principle used by TDS Execution
> Protection, or even my app, TrojanHunter Guard?
Not quite! You're referring to two very different techniques here, neither of which are directly related to unpacking.
TDS Execution Protection intercepts executables _before_ they are even loaded into memory (and we've improved on this for TDS4/Wormguard4 with new kernel-mode drivers), allowing TDS to scan the file for trojans, and if any trojans are found the execution will be immediately aborted so the trojan won't run - it won't even be loaded into memory. TDS also has powerful memory scanning capabilities, but that's in addition to execution protection so you get the best of both worlds. TDS is the only anti-trojan system with true execution protection capability. Other anti-trojan systems wait until the trojan has infected the machine before scanning it by using a polling technique where every xx seconds the current process list is checked, and any new processes are then scanned. From our experience this is far too late because the trojan has already had the chance to execute, at which stage it can then immediately take out any resident security programs before the security programs can react.

Unpacking can be tied-in with execution protection, but it cannot be used for process memory scanning because the unpacking has already occurred, so unpacking is only useful for files, not processes.

> Isn't it impossible to alter the actual process signature (not the file signature)
> without completely rewriting the malware and changing it into something else?
No, it's actually quite easy. Assuming we're dealing with a trojan server that isn't packed, any changes you make to the file will also be reflected in memory, so if you know where in memory a trojan scanner is looking to detect a trojan you can easily determine where in the file that same section of code/data is. There are many tricks that can be used.

> If you altered the process being run in memory, it would no longer be "SubSeven"
> or "Opaserv", but a completely different trojan or worm, right?
No, it would just be a modified variant. Functionality-wise it would still act and behave exactly the same. The modifications made by a hacker would typically be targetted at one scanner though, because all scanners detect in different ways.

> This does point out limitations of signature-based scanning, but I'm
> skeptical about how easy it is to actually change the signature of a
> running process in memory, without completely rewriting the malware,
> as Gavin suggested
It's very easy to modify process memory, that's not really a hurdle at all, and the hacker doesn't need access to the source code of the trojan, he just needs the server executable. It's also very easy to make launcher apps that can be bound to trojans, that launch the trojan and then immediately modify its process memory, this way there is no need for the hacker to modify the actual trojan until it is in memory. There are many techniques, too many to go into here.

Did I miss anything?

Best regards,
Wayne

 

That pretty much describes my setup
I too run regprot (as suggested)
A Router NAT Firewall (In addition to ZoneAlarm)
Naviscope (as a freeware Proxy)
FileChecker (the watcher for the watchers)
I also have TDS3 configured to scan everything but ADS streams at startup
(takes awhile considering the size of my storage)
And of course both Wormguard and TDS3 exe protection
I also leave TCPView running on my 2nd monitor
(Its a freeware utility that isnt as nice as Port Explorer,
but Ive been spending on hardware lately..need more boxes )

and if you havent already,
install all security to nondefault directories
ie: Wormguard to C:Wurm

The next level would be multiple OS\network topology, Packet Inspection and Intrusion Detection (like Snort), Im still in the process of building the boxes and learning Bastille Linux, and OpenBSD as external Guardians to my Win32 boxes,
as well as a planned DMZ Honeypot


Howdy Wayne ( lookin forward to TDS4 )

 

>To an extent - it makes detecting the original file harder as it has
>to be unpacked, but detection of the packer itself is usually very
>easy - just look at the code at the entrypoint, it will be the
>unpacker.

Most products are using polymorphic decryptors or unpackers. So its not so easy as you said. Look at y0da, armadillo, asprotect etc. ... .

>The unpack engine we've already developed for TDS4 (which
>currently successfully unpacks all ASPack, Petite, UPX and various
>other packers) essentially allows the unpacker part to run up to the
>point where it hands over control to the OEP, at which time a
>snapshot can be taken of the unpacked code. The unpacked code
>is never executed.

I hope you will check the unpacker if it was modified. Otherwise TDS will be a nice virus spreading machine . By the way ...

Using breakpoints (and this is execatly what you are doing) is very dangerous and very easy to circumwent and "break out". There are more powerfull ways using emulation (KAV, McAfee), a virtual PC (Norman, but i think it does not use it for unpacking) or protection layers (at the moment no programs uses such a technique) .

>TDS Execution Protection intercepts executables _before_ they are
>even loaded into memory (and we've improved on this for
>TDS4/Wormguard4 with new kernel-mode drivers), allowing TDS to
>scan the file for trojans, and if any trojans are found the execution
>will be immediately aborted so the trojan won't run - it won't even
>be loaded into memory.

But not every time in version 3. Just start the program from the console or due a batch script or simply use CreateProcess API instead of ShellExecute. But this will be fixed using a kernel mode driver.

>TDS is the only anti-trojan system with true execution protection
>capability.

You are wrong, look at PestPatrols OnAccess Scanner.

>From our experience this is far too late because the trojan has
>already had the chance to execute, at which stage it can then
>immediately take out any resident security programs before the
>security programs can react.

Thats right.