Sunday, August 30, 2015

Continuous training

Somehow I get tangled into continuous training session starting from 12th till 31st  August, spanning over weekends too and being spread from Middle East to back home.  Actually a horror to get trough
because it drains me down completely and re-position my beloved vacation. It also includes about month of preparation before.

For me the most interesting part was Linux forensic intro and preparation for it, this is  training which regrettably goes very seldom so I have to do humble, detailed preparation, check all examples and include recent developments.
Training was fun but very short on time, just 3 days planned but in reality even shorter,  Also it was exhausting for me as trainer and for students too.  There was huge amount of command line actions, what is so uncommon in today computing.
When we are talking about Linux and forensics it is about to cover:

  1. Student mindset about using computer
  2. Linux as working platform, from user view, over sysadmin view to system programmer view (and system programmer view is what is actually what forensic view is about)
  3. Linux as forensic workstation, tools and concepts 
  4. Linux as forensic target 
So it is huge task even just to mention things ...

Rest of the training is small Encase Forensic 1 and Forensic 2 class, almost private tutoring, it is also a challenge with ever changing Encase v7  you never know what will happen if you don't check all examples in exact combination of windows, patches, security software and Encase. 
As for annoying examples in v7.10.5 suddenly VDE refused to work, but it was still OK on v7.10.4 so you never know what will be exact situation, if you can not have a sterile dedicate classroom.







EnCase v7 and node sweep for hash suggestions

Just been trying to do node sweep for dll and process hash, to do some presence control it turns out in v7 you can't do normal check for list of hashes without enscript programming. Very frustrating since in v6 it was possible at least to find end nodes with required hash trough conditions.

In version 7 there are no conditions in sweep snapshot results also in case analyzer part restraints are so dumb organised that you can't do a list of hashes but one by one trough immensely dumb interface. It is frustrating since user interface is lame worst of it data are there but you can't get to it.. kinky and masohiticly perverted. Before I've been able to access data from infozoom but test licence is long gone so we are back on Enacse functionality.  Other patch was to print hash in console and do unix fgrep on the console output, it worked but is was awkward also.

Since I mentioned enscripting to solve my issue, examples which are provided in manuals are not complete. It is easy to do a sweep, and get dll and process hashes, but what is missing completely is how to compare it with existing hash sets in hash library.That will be  the elegant solution,  to create a has set add it into has lib and that find if collected process hash or dll hash belongs to set ... if you can find example :) :)

Also the idea of enscript programming is very outdated in sense of what kind of programming language enscript is, It is so low level access to encase internals, like using C code to do ls and cd command each time. Putting a "script" into name is also a bit perverted,  it is en-script .. encase scripting language, but as far from concept of scripting as can be. To be efficient and useful powerful simple scripting command is needed not C++/java language concepts.  Instead of endless low level object and classes meddling simple high level construct should be used.

Something like this, it is easy to read even for someone who does not know programming, if he is familiar with enacse enterprise concepts

do sweep on node1, node2 use systeminfo, snapshot
     when node in sweep
           if node process hash is in hashlib bookmark node, process, hash
           if node dll hash is in hashlib bookmark node dll hash

or whatever else familiar syntax , I've put a bit of this thoughts about standardization and basic case handling testing, comparing results in other earlier posts and forensic language issues.

Modern languages python, ruby, even perl or forgotten tclsh are powerful languages easy to extend and use,  almost platform independent. Python is the star at the moment so why not python .. don't know but there is a lot of work, oddly to communicate with python tools outside of encase and collect results, what is again a bit against the idea since scritping language is mentioned to be a glue layer among other modules exactly the opposite :) as it is used here.

Ages ago in late 1990s during my phd I was doing almost the same concept to merge two different tools, snmp and fuzzy data expert to interpret data collected from snmp. It was before python and shell was simple tcl functional extension able to code fuzzy rules into code as simple human readable statements. It can be done even for much more fuzzy concepts than forensics

When we are mentioning using programming in digital forensics it is very good idea to study in detail concepts and implementations of coroner toolkit and sleuthkit, since it depends on known and forensically sound system level library's and system calls,  If we are talking of using scripting language in digital forensics some checking on implementations on different platforms should be done or even better, creating a new forensically sound libraries or classes.  It is illustrated in earlier article about python scripting "Python training for forensics"  where some issues in ordinary IO mechanism is mentioned, which if we are strictly speaking about forensic (in sense of its rules and requests) should be done in basic IO level.  Almost similar discussion exists in V.Wenema book about digital forensics taking great care about cache issues on unix file system.






Friday, August 7, 2015

TD3 and linux

While I was preparing myself for linux training I've decided to connect TD3 over iscsi to SIFT 3.0 workstation as example. It takes about few minutes and some man page reading. Easy and simple and works.

Sans SIFT 3.0 workstation is Ubuntu based and open-iscsi package is not installed, so first thing to do is to install package. On Ubuntu wiki there is enough technical details.

> sudo apt‐get install open‐iscsi

That will add and configure iscsi subsystem on Sift, on TD3 iscsi should be enabled and restarted few times to get it running. It's common situation with TD3 and iscsi connection. Don't forget to take IP address of td3.

To do dummy check it is good idea to ping TD3 and see if we can reach it

>ping TD3IP

On Sift iscsi discovery will show if  we can reach isici targets

>sudo iscsiadm ‐m discovery ‐t st ‐p TD3IP

1. -m: determines the mode that iscsiadm executes in.
2. -t: specifies the type of discovery.
3. -p: option indicates the target IP address, in our case TD3

After that  we can login into TD3 and access sicis target

>  sudo iscsiadm ‐m node ‐‐login

If all is ok, message about success will be display and new disk is visible
dmesg command should who it also

>dmesg | grep sd

so we will have new local disk  on Sift, ready for use, already read only exported from TD3
any standard command should work, even mount

if we need to remove disk and its file systems we have tpo do umount first and than disconnect the disk session.

>sudo iscsiadm ‐m node ‐u