Let's get some ideas for classification out then. We could classify by type of malware, or by symptoms (my favorite because I generally can see the symptoms), or we could classify artifacts by locations but as you say, that can morph. We could borrow from another science and classify by the "skeletal" appearance of artifacts. All of these are merely off the top of the head and have no fleshng out applied.
As for the "reformat and reinstall" debate, I'm afraid business and revenue forces form the higher powers will dictate UNTIL we develop an alternate solution that will eliminate "costly" downtime and production time.
Bill
Would it be tough to maintain? Perhaps. But maybe what's needed is a slightly different approach…an artifact "library" sounds too much like a signature-based approach, and signatures can be hard to maintain. How about a framework for understanding how artifacts are created, and where they might be located based on different scenarios (remote compromise, etc)?
H, I am having a hard time wrapping my brain around what you are suggesting. Signatures can be comprised of many different types of data - (code sequences, registery entries, unique character strings in files, etc.).
What would you consider to be a valid artifact? How would your artifact be different from a signature?
Would you clarify your statement as it pertains to framework!
How about a framework for understanding how artifacts are created
I'm thinking of framework as implementation level or wrapper code not potential tale-tale signs like (log entries or ip addresses).
I would agree that sometimes certain remnants can be good indicators of suspicious activity. Would by chance what I'm referring to as remnants(log entries-"You have been hacked!", e-mail subjects like "Good News", etc.) be classified as "artifacts".
Bill,
Re classification. I'm not looking at a purely symptom-based approach, b/c as I mentioned in my blog, many times I'll get a case and the incident report from the customer, and all interviews, end up having nothing to do with what really happened.
I'll have to consider the taxonomy a bit more, but I am open to input from others.
> UNTIL we develop an alternate solution that will eliminate "costly" downtime and production time.
We've already got that…configuration management. Oh, wait…the corporate bigwigs aren't paying for that either. Okay, how about training your IT staff so that they have the knowledge to perform a root cause analysis, so that they can do it in a timely manner? Oh, darn…no, the honchos aren't paying for that, either…
A light blub just blinked on for me! H, are you considering building a library of just "artifacts" of malware residue or a comprehensive library.
Good Idea! Document past events and providing value to the customer!
A system could be scanned for this malware residue, indicating previous activity. At least from my experience, I'm usally involved two, three or more events later.
Is it your intention to track current malware,viruses,rootkits as well as any residual remains?
Hogfly,
Funny…Will Smith's new movie has a scene where the main character says, "People will tell you something is impossible because they can't do it."
I don't think that an artifact library is difficult to develop…as you've pointed out, there are already several out there. With MetaSploit, you could easily document artifacts based on exploits available in the framework.
Would it be tough to maintain? Perhaps.
You're right, I meant maintain rather than develop.
But maybe what's needed is a slightly different approach…an artifact "library" sounds too much like a signature-based approach, and signatures can be hard to maintain. How about a framework for understanding how artifacts are created, and where they might be located based on different scenarios (remote compromise, etc)?
After all, even though there are malware toolkits out there, the number of places within the Registry where you can autostart something is finite. Also locating executables isn't all that hard, if you think about it.
> Someone *could* write a crawler
Funny. Rather than putting that off on someone else to do, would it be possible to come up with a concensus, or at least have a discussion about classifying artifacts?
Fair enough. I assume then that you are working on this already and are looking for input. So, perhaps the most logical thing to try is to use what already exists and let's see if it applies here. Let's take applied criminalistics for instance.
First, we have class characteristics - that which applies to a class of evidence; a footprint.
Next we have patterns - Let's say..an adidas shoe print, size 11.
Finally we have individual characteristics - using the shoe print, let's say there's a drag on the left heel that could be used as an identifier.
If we take these characteristics and compare them against a suspect that owns adidas shoes and has a drag on their left heel when they walk..we might have a match or an identity. The actual match could be the mud or dirt found on the suspect's shoes.
Or better yet(and simpler), if it looks like a duck, quacks like a duck, walks like a duck and has duck feathers then it's likely to be a duck.
So, can we apply this to malware? Absolutely. Malware already has classes Trojans, blended threats, spyware, rootkits, bot software etc..
Each of these classes has a pattern. A trojan may open a port for remote control, a blended threat when extracted may contain a series of tools, spyware contacts a specific vendor or site and so on…
Next we have individual characteristics. This may be the hash of the file, or the specific mutex that gets created, or perhaps something embedded in the code of the executable.
So, is this an applicable framework? Yes. But is it the right one?
az_gcfa,
you said, "…are you considering building a library of just "artifacts" of malware residue or a comprehensive library. "
In an earlier post, I'd said
"…an artifact "library" sounds too much like a signature-based approach, and signatures can be hard to maintain. How about a framework for understanding how artifacts are created, and where they might be located based on different scenarios (remote compromise, etc)?"
Hogfly,
"I assume then that you are working on this already…"
Never assume, my friend. It's something I've been tossing around in my mind, and on some crumbled pieces of paper, but I wouldn't really say "working on". However, I am looking for input. And your thought process from your last post is moving right along the line of thinking I've been getting at.
One of the side effects of something like this is that (I hope) folks will be able to better describe what they're seeing. In some ways, I'd liken it to how doctors diagnose a patient or how an LE investigates a crime scene. I'll tell you up front, though…I'm going to sneak a little Deming in, too, as making decisions based on empirical evidence is much more accurate than by emotion.
To your final question…is it the right one? Maybe not…but at least it will be one. Right now, there really isn't "one". In fact, in many cases, there isn't any sort of framework at all…it's more of an "OMFG, I think I've been p0wned!!" panic reaction than anything else.
Well slap me up side of the head and call me stupid! I thought my question was valid! You were never clear as to what you meant by arificats residual file remains, actual malware (executables or containers) deactivated or dormant, potential trace evidence (different than residual [ip addresses or log entries]).
It was my impression that you per proposing a tool to be used for image analysis different than current malware,spyware and antivirus tools. Plus, you were not clear as to wether this tool would be used in conjuntion with other tools or simply standalone.
Reckon - I must have cast a shadow on one of your previous Sunny Days! OK! I'll retreat to the shadows - you've made your POINT!
All,
First off, I'd like to hear how folks are scanning imaged systems for malware. I know that you can mount the image in EnCase's virtual file system, or you can use LiveView to open up a dd image as a running system in VMWare.
Given, say, just a dd image, what are some other methods for scanning for malware?
This brings me to the issue of artifacts. Do you think it would be feasible to develop classes of artifacts such that exploits or other issues (malware, etc) could be easily culled from an image?
Harlan
First Question
Sometimes scanning "for" malware is not what you need. Scanning for malicious changes…that might be eaiser.
If the system is so important that knowing if it has running/stored malware is critical, then maybe its important enough to keep a "library" of hashes off all the main directores and the files contained within.
Then check for malicious changes…instead of for malicious software.
That signature DB is easy to maintain.
–basicly– Host Based IDS
And Second question.
No, not feasible. Try catigoirzing vulnerabilites first, and I think you would run into many of the same problems.
* Some of my own comments.
Remember that if you are at this stage then virus protection, access controls, and other controls have all failed.
So what is it about your tests/scan of the DD image that is going to be different?
What do you want to accomplish? Verify that the system was hacked? Verify that data was stolen? Verify that the system wasNOT vulnerable and the state it is in is the direct result of intentional user interaction?
Skip