I saw the topic mentioned, so I thought I'd start a thread…
I guess the first step is to determine where you want to stand on the issue…do you want to prove or disprove the claim that a bit of malware was at fault? I think that this is going to be more of an issue, as malware (to include spyware and adware) continues to grow (in capabilities) and proliferate.
So, how would you go about this? As I've blogged about (blog listed in .sig file below), on XP systems, you could check the contents of the Prefetch directory to see if (and possibly when) the malware was executed. Of course, you'd also have to check the deleted files to see if a Prefetch file was created, and then deleted.
One way of determining intent would be if the files for the Trojan existed on the system, but the usual suspects are not located within the Registry (ie, "Run" key, etc.) - this may indicate that the user himself copied the files to the system, but never actually installed it.
What else would you look at? Try to be specific with regards to OS, versions, applications (and versions) as necessary. Some versions of os's or applications may not have capabilities of later versions. Saying "Windows" isn't very helpful, unless the capability or functionality applies to all versions.
H. Carvey
"Windows Forensics and Incident Recovery"
My approach to this is as follows:
1. Determine if it exists. Mount the image and run virus scans against it (Encase VFS or Paraben's new product). I usually will go with three different products. One big name product (ex. Norton) and a couple of specialty products (ex. TDS3). Remember however that it's not a good idea to have more than one AV application installed on a computer. Generally install, scan, and remove the application then repeat the process. It's not uncommon to get different results.
2. If step one yields positive results research each, find out where it installs itself, what the capabilities are (could this virus cause the results claimed), and whether it's functional in the case at hand (just as keydet89 pointed out). This is where you go into the registry, autostart locations, etc. Create a hash set of a test system. Then install the virus on it and hash it again. Look at the files that have been added or changed. Compare with the subject system.
3. Check for the source of the infection. Downloaded files, email attachments, etc. If this can be established any evidence that can be sourced prior to the infection will have more standing.
4. Check for the source of the evidentiary data. Do facts exist to prove it wasn't the result of a trojan horse?
5. Check for the possibility of self infection. Internet search terms for trojan horses, downloads of the same, other research on the topic, incomplete or no installation of the virus, etc. Especially in the time frame immediately prior to the infection.
6. Did the user have an AV application installed? If so was it current? When was it last run? This can all usually be determined from the "program files" folders for the application. Was it capable of detecting the infection? How does this compare with the user's story?
7. If necessary restore the evidence files and boot the system. Run a sniffer and see what's going out or coming in. This is not conclusive either way, as many trojans will lie dormant until accessed. Still may be helpful as one more piece of the case (to state it definately was working, or may not have been working).
I don't think a case is made or lost on the presence of a trojan horse. It just requires diligent use of good examination practices. I realize that most of this is not OS specific, but the steps are the same regardless. A little more difficult on a system such as a Mac, Linux, etc., but none the less possible (one of my most challenging cases involved a search for trojans on two ibooks).
I guess the first step is to determine where you want to stand on the issue…do you want to prove or disprove the claim that a bit of malware was at fault?
I think the examiner is better off just focusing on the facts. Let the attorneys do with those facts as they will. If there is reason to believe that a trojan exists then look for it every way you can. As an examiner I am only beholden to the truth; we can't go into examinations with a prejudice of what we want the outcome to be.
Sorry but you have both missed the point.
The point is the virus/trojan/whatever you want to call it does NOT actually exist. The accused just claims "I didn't do it. It was an unknown virus"
And there is the problem. Because it's an "unknown virus" you won't find it. (because it doen't actually exist). All you could state in court is you didn't find the virus, not that it doesn't exist.
You would then leave doubt in the minds of the jury. The problem is Is it reasonable (whatever reasonable is) doubt?
A nineteen year old hacker used this defense and got off.
So you go to court and when asked if a trojan horse was found you say "it doesn't exist". Then they say "So you looked for it how?", to which you reply, "I didn't look for it, it just doesn't exist, it's a phony alibi". I don't think that's going to score you many points.
Sure it's an alibi that's claimed often and rarely true (if ever); but if the burden of proof lies on your side you'd better be prepared to cover all the avenues.
While it's harder to prove something doesn't exist (think bigfoot) it's not impossible to build a strong case. That's why you go further than would be considered reasonable means to find it. Your report contains lines like "I used three anti-virus applications, each of which I know to be capable and reliable methods for finding virus' on computer media". It's not a perfect alibi. While there are some high profile cases of it, much more often than not it doesn't work.
An interesting note about spyware..we(my employer) has been in a fairly large battle with Marketscore(a spyware package that sniffs SSL traffic by routing through their proxies)..it's intent is for "research" although it clearly violates laws.
I think what is key to this issue is whose network is the suspect using? Is it your corporate network or an ISP's?
If it's a corporate network, *hopefully* a policy is in place for events such as this.
Typical procedure includes contacting HR to get approval to conduct network forensics on suspect's activity, installing a packet capture device at network choke points.
This includes: full content capture (tcpdump -s 1515), session/flow capture(argus,cisco flow logs), and statistical reporting of usage.
The same can be done under subpoena for an ISP.
Unless I am mistaken, ISP's must keep session data logs (flow logs) for a period of time.
Why do we do this? Trojans don't control themselves. Malicious people control trojans. If a rootkit was dropped and the machine is connecting to an IRC C&C and you capture the PRIVMSG's or other such traffic you can invariably determine that the user is not at fault.(this has become the norm in the past year) UNLESS the traffic is control information.(this indicates typically indicates that either the machine was compromised remotely or the user set up their machine to be the controller).
Simply put if a malicious "hacker" is using the system, and you are performing adequate network forensics at the network choke points, you will most likely see the connection from an outside source to the machine in question before you see outgoing connection attempts (unless it is phoning home.) So, if you are lucky you can capture network traffic to back up or refute the "trojan defense" claim.
How do you determine who is at fault?
If someone is suspected of doing something illegal, after following SOP for responding to an incident, attempt live capture(helix,WFT,FSP),pull plug, image, hash etc..
load the image in to analysis workstation. Mine typically happens to be helix or a windows box with FTK.
How do you rule out self infection?
FIND THE BINARY.
This is key. Hopefully you are provided with a tentative date to begin searching. Otherwise it's a bit of hunt and peck.
If you know you are looking for a trojan/rootkit/malware etc.
Consult live analysis information looking for clues.
I am not going to fill in the hashing sequences as that part should be routine.
in helix: run sorter and look for mismatched executables,images, or text files. Typically an ini file is used..I've seen them listed as .gif and other extensions, hence the need for checking mismatches. Assuming you find the binary, record MFT and inode information.
If you can find the binary then you can do a number of things. This includes searching for the .pf files potentially associated with the binary to determine time of use(this can be important if you have the network logs to compare), MRU keys, MAC times,
*Note* this is important because you can determine *how* the binary came in to existence on the machine. Was it unzipped with a program that was already on the computer or did a compression utility accompany the malware? If it was unzipped by a program already in existence then you can determine the infection was intended since most unintended installs are either self unpacking upon execution or are bundled with a decompression util.
prefetch files show up in the timeline in autopsy(fls).
Next comes sandboxing, and finally reverse engineering the binar(y|ies).
Carve binary and related files from the image.
Load image on to sandbox. (my sandbox/binary analysis machine is XPSP2 with vmware running 4 VM's (vmware 4.x)in host only mode).
Scan binary with SAVCE,Mcafee,ClamAV.
Submit Binary to: virustotal.com,
Record results.
Unpack binary if neccessary(lordpe, various unpackers, PE explorer)
Run binary in sandbox:
Run regmon,filemon,process explorer, and tcpview,ethereal.
Record results.
Compare results versus sandbox.norman results.
Does it phone home? What's it doing on the network? Does it attempt to spread? Does it open a listener? Is it the server or client? What libraries(dll's) does it call? If the binary was installed by someone else it will typically open itself for contact by an outside source.
If results of tests are inconclusive, reverse engineer the binary. I rely on IDA pro & ollydebug..some people use gdb. This may or may not be worth it but in a landmark case like the trojan defense case in the UK..it should be done since there could be clues in the binary including Mutexes or messages that indicate who created the file.
Other utliities used:
spybots&d
hiijackthis
spysweeper
Tauscan
TDS-3
thecleaner
*more recently* rootkitrevealer
Another utility I am beginning to work with is prevx (
Don't know if this is what you were after Harlan..
P.S. I didn't know you were blogging until you mentioned it in the other thread about prefetch.
Daveg: That case was royally botched by the prosecution.
Excellent posts gmarshall139. Thanks a lot.
Sorry, daveg, I believe it is you that have missed the point on this occasion.
I will second the tds-3 program. We use system suite, trend micro online, norton, tds-3, spybot, ad-aware, hi-jack this, cw shredder, and one or two others. This allows us to give a very detailed report on what we did or didn't find in relationship to this type of defense.
Don't forget to check logs for the various programs. They may have had a virus and gotten rid of it or quarantined it.
Food for thought, we've had success with telling the defense to show us evidence of a virus, not just making accusations about them. The way we put it is if you say there is a virus put someone on the stand to talk about the virus they found and what it does. If it's all a bluff they won't be able to. Our prosecuters have successfully argued this during closing arguments, enough to sway a jury.
-Dawson
Looking beyond the normal areas of analysis we all know AV s/w is not infallable; evidence of malware activity (previously known or otherwise) can also sometimes be seen in client firewall logs (assuming the machine was using such). Connections be it via IRC, SSL or even just standard HTTP to unknown or 'unusual' sites may be indicative of such - regardless of what you find in analysing the binaries on the Machine. At least it can create an element of doubt - if well presented. Looking up suspect or suspicious IPs taken from the FW log in a good AV/Malware research database can be helpful if for example the target connection IP address is known or associated with malware, or even has been used previously by malware services. MPACK Hacktool attack web server IP Addr in the client FW log would be one such example, … ISP logs another.
Example Initial MPACK infection does not leave a tangible file behind as evidence, but redirects the infected machine to the MPACK Webserver- afterwhich the trojan/agent is downloaded. This tied up with Armresl's advice may help at least put the matter more conclusively to rest.
I maybe 'preaching to the choir here', but; the owness should not simply be on one party ie. defense to prove a case; but ethically - it should be one both parties to prove/disprove any possible causes beyond malicious user intent that the suspect did or did not do what is alleged. As an investigator whose findings may result in a person being wrongly or rightfully convicted; it weighs heavily on the investigator to ensure that every conceivable angle has been covered or taken into account.
Just a thought.
Depends on the crime doesn't it?
What is the malware being blamed for?
A remote access trojan isn't going to open IE and leave browser artifacts is it? No, but a perv would.
A remote access trojan wouldn't install kazaa and start downloading unlicensed software would it? No, but half the country is.
I bet the lawyers are gonna love this.
Harlan,
I guess you are asking, how would we prove or disprove something like this?