Malware risk mittig...
 
Notifications
Clear all

Malware risk mittigation on forensic workstations?

9 Posts
6 Users
0 Likes
868 Views
erowe
(@erowe)
Posts: 144
Estimable Member
Topic starter
 

Does anyone have any thoughts, references, research, or other materials on procedures or good practices to mitigate the risks to an examiner's system from malware that might be contained in an image?

I've been asked to put together some information on this and while some posts talk about using multiple virus scanners on images, that only finds the malware. How do you then protect against it if the viewer you're using for the infected file might make the malware run and infect your computer?

Re-imaging between cases or using VMs may be a solution, but this may not be practical in some environments.

 
Posted : 14/04/2015 7:55 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

Does anyone have any thoughts, references, research, or other materials on procedures or good practices to mitigate the risks to an examiner's system from malware that might be contained in an image?

I've been asked to put together some information on this and while some posts talk about using multiple virus scanners on images, that only finds the malware. How do you then protect against it if the viewer you're using for the infected file might make the malware run and infect your computer?

Re-imaging between cases or using VMs may be a solution, but this may not be practical in some environments.

I am not sure to understand. ?

I mean malware is not "poisonous" or "radioactive", you need to actually RUN an executable of some kind to make it active.

And this is not was normally is done on an image. particularly an image that should not be modified in any way.

Which kind of "viewer" do you have in mind that might possibly activate the malware?

You mean inspecting the contents of a .pdf or a .html or the like?

jaclaz

 
Posted : 14/04/2015 10:46 pm
(@paul206)
Posts: 70
Trusted Member
 

I'm with jaclaz on this one. Everything on your hard drive or image is static. You are not going to go around activating executables. Malware in a pdf is possible but less likely. It's like my old boss used to say; "Security is not about eliminating risk, it is about managing risk." If you keep your Windows environment healthy you increase your chances of stopping or at least being alerted to something that does get in.

I think common sense would apply here. I imagine that if you show you made a good faith effort to keep your forensic workstation clean you would be ok. Regular stuff like;
1. Install a brand name anti-virus like Norton.
2. Install and run Malwarebytes regularly like once a week, or better yet, pay for it and leave it run all the time.
3. Regularly run Windows Update if you are not live.
4. If you are live put Windows Update on auto-install.
5. Regularly update all your other software.
6. Decide what your policy is regarding a live internet connection. Standard practice says no. What I did was to hook up an ethernet A/B switch. One side is live and one side is not. I leave mine live and turn if off when I want. Others would leave it off and turn it on when they need it. Just make up your mind and have good justification for it. I am behind a stack of routers and firewalls so I don't worry so much about someone getting in.

 
Posted : 15/04/2015 12:14 am
(@c-r-s)
Posts: 170
Estimable Member
 

Forensic workstations truly represent a huge attack surface Content processing (like Oracle Outside In, a popular target, as it is shared with MS Exchange), file system parsing, search indexing and so on, in many cases run as admin/root.
However, for these opportunities of exploitation, you can assume a targeted, sophisticated attack, which cannot be effectively countered. You already mentioned the most effective and practical ways of mitigation. On Windows machines additionally have a look at Microsoft Applocker. It's nice to have, but it won't help much under the described thread model, to be precise at best, if your exploited application runs as a standard user.
Handle files as passively as possible Don't use Anti Virus on your examination system. Don't apply foreseeable procedures like AV scanning to files, which you actually don't need to have a look at. Inspect content on low levels, like hex dump, or selectively by using meta data viewers before you feed them to standard viewers.

 
Posted : 15/04/2015 1:30 am
Chris_Ed
(@chris_ed)
Posts: 314
Reputable Member
 

Inspect content on low levels, like hex dump, or selectively by using meta data viewers before you feed them to standard viewers.

I understand what you're saying, but I'm not sure the above is always feasible - if you have 300,000 jpegs to process, can you check the raw data for each one to ensure there isn't an exploit present?

 
Posted : 15/04/2015 1:36 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

Let's try to "limit" the scope by inventing some completely fake probabilities 😯 .

Everyone seems to agree that NO executable inside the image (i.e. no .exe, .bat, .cmd, .vbs or powershell script) will EVER be executed, and this cuts out - say - 99.17% of malware.

The remaining 0.83% can belong to

  1. 0.13% Office Macro or VBS <- Solution/suggestion DO NOT use Office to open Office files, use a viewer or an alternative program that can open .doc, .docx, .xls, .xlsx, etc., at least on first inspection of the file
  2. 0.08% Javascript, java or other scripting in .htm/.html pages <- Solution/suggestion DO NOT enable script in the browser you use or use at least on first inspection of the file a browser WITHOUT this kind of script support
  3. 0.22% System induced like the periodical issues that come in windows about some stupid buffer overflow or similar connected with fonts, bitmaps and similar<- Solution/suggestion make sure that your OS is current with latest patches (see also note 1 below)
  4. 0.34% Other exotic forms of malware more or less connected with malicious code embedded in a data file but targeting - just like the previous one - a specific "default" behaviour of the OS (like - say - file association, DCOM, etc.) <- Solution/suggestion disable/replace/change as much as possible "default behaviours", "file associations wih built-in Windows programs, etc."
  5. 0.13% Other even more exotic forms of malware that are undetectable or can however go undetected but that need a particular/peculiar/specific set of conditions (let's say be connected to a given network, only run on the third friday of the month or if the GPS coordinates of the machine match a given set) Solution/suggestion nothing really needed or generically applicable
  6. 0.06% *something else* Solution/suggestion nothing really applicable
  7. [/listo]
    Of the above, 89.37% can be anyway (before and outside the recommended solution/suggestion) found by common antimalware/antivirus scans of the image, which can be carried as a preventive measure on another dedicated machine before the foeensic examination.

    Consider also how normally (with the exception of real time attacks and counter attacks and incident response for intrusions) there is a time delay between the moment a disk is seized and imaged and when it is examined, from days to months, so there is, even in the case of a "very new" malware, the time for the good guys to update the malware/antivirus definitions and the malware won't be "very new" anymore.

    jaclaz

    Note 1
    A line might be needed to be drawn between different kind of cases/scenario's
    Scenario A Forensic examination of a computer belonging to an average Joe Smith suspected to have attempted killing his wife probability of finding on it something that escaped the previous preventive measures 0.01%
    Scenario B Forensic examination of a computer belonging to another average Joe Smith suspected to be in possession of illicit images probability of finding on it something that escaped the previous preventive measures 0.02%
    Scenario C Forensic examination of a computer belonging to a "plain" Corporation/Office, let's say a Real Estate one, where there was an intrusion and the hacker replaced all images of houses and flats with pornographic images, leaving additionally a "Kilroy was here message as desktop background probability of finding on it something that escaped the previous preventive measures 0.03%
    Scenario D Forensic examination of a computer belonging to a Bank/Credit card issuing entuty, let's say American Express, where there was an intrusion and the hacker harvested all people personal data and sent money to a zillion untraceable accounts in 214 countries probability of finding on it something that escaped the previous preventive measures 0.1%
    Scenario E Forensic examination of a computer belonging to the military, let's say the Pentagon, where there was an intrusion and the hacker harvested all nuclear missiles activation codes probability of finding on it something that escaped the previous preventive measures 1.2% (but on the other hand it is unlikely that you will survive to actually carry on the examination)

 
Posted : 15/04/2015 3:17 pm
erowe
(@erowe)
Posts: 144
Estimable Member
Topic starter
 

Maybe I should have been clearer on the context for this in my first post.

Where I work we deal with a lot of Word, Excel, and PDF documents (although we deal with every type of application and document depending on the investigation). They typically get examined in FTK or EnCase and exported to tools like Summation or Ringtail typically along with large amounts of email.

They all have to be opened and viewed at some point. This means that the viewer could potentially allow a macro-virus or other document associated malware to run. This could infect the initial analyst machine as well as any other machine the documents eventually get viewed on.

A further complication is that some of the investigators aren't tech savvy and might export the documents to their (networked) workstations to work on and refer to when they write up their reports.

So given this context, what should we be instituting in terms of good practices to mitigate against infection.

Unfortunately this isn't just a theoretical problem. A colleague of mine at one government agency was involved in a scenario similar this.

 
Posted : 15/04/2015 7:53 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

Maybe I should have been clearer on the context for this in my first post.

Where I work we deal with a lot of Word, Excel, and PDF documents (although we deal with every type of application and document depending on the investigation). They typically get examined in FTK or EnCase and exported to tools like Summation or Ringtail typically along with large amounts of email.

They all have to be opened and viewed at some point. This means that the viewer could potentially allow a macro-virus or other document associated malware to run. This could infect the initial analyst machine as well as any other machine the documents eventually get viewed on.

A further complication is that some of the investigators aren't tech savvy and might export the documents to their (networked) workstations to work on and refer to when they write up their reports.

So given this context, what should we be instituting in terms of good practices to mitigate against infection.

Unfortunately this isn't just a theoretical problem. A colleague of mine at one government agency was involved in a scenario similar this.

Yep, but before being provided to the non-tech savvy investigator, can these documents be scanned by a common antivirus?
This will effectively remove or at least warn about the large, large, large majority of known virus/malware.

About Office documents, Word, Excel and similar, as said UNLESS they are open in the associated MS program there is no chance that the macro or VBA (or whatever) will be run, you can use OpenOffice/Libreoffice or - say - Softmaker or Kingsoft, they all offer a good enough compatibility with the actual documents but they will simply not "initiate" the running of macros and similar.

Same goes for .pdf, still say, Foxit or even the simpler Sumatra .pdf give usually a high level of compatibility while being very unlikely to trigger any embedded malware.

The few, very, very few documents that fail to open in the mentioned alternatives to their "native" programs may well be "isolated" and sent for review to an actually technical savvy investigator that would examine them - for added security - on an "expendable" machine (like in a completely RAMDISK PE, or in a full Windows install with techniques *like* Deep Freeze or Steady State or similar or running from a "run-once" Windows .vhd install, etc.).

Of course you cannot have (as you can never expect to have it when security is the topic) 100% certainty of course, the mentioned suggestion only work to make probabilities of getting affected by such a malware so low as to be in practice of no relevance, let's say that in 99.99% of cases you are perfectly safe if you take these steps and 0.01% you are not, but NO WAY exists to make this residual 0.01% equal to 0.00%.

jaclaz

 
Posted : 15/04/2015 10:52 pm
(@athulin)
Posts: 1156
Noble Member
 

So given this context, what should we be instituting in terms of good practices to mitigate against infection.

Do a proper risk analysis. Identify the risks (the unwanted events), grade them as to likelihood, and damage, ignore everything that ends up below your threshold, do a root-cause analysis on the rest, and decide how to prevent risk, mitigate it, transfer , or even accept it. Standard operating procedure, more or less.

I mean … one simple solution that seems to meet the requirements you've mentioned seems to be to let someone else do the job that way your systems won't be infected at all.

Just accepting someone else's list of risks does not necessarily do anything towards addressing *your* risks you may grade them differently, both as to probability and as to damage.

The ideal thing would be to have a kind of 'format x lint' tool that checked the data file for strict conformance to format specification. Anything out of the ordinary would cause a warning, and prevent further automatic processing. But I don't think we have anything like that.

 
Posted : 17/04/2015 8:49 pm
Share: