In one of the interesting conversation with a legal team I came across some interesting question, one of them was in regards is the integrity of mails met in pst files.
Well what i understood from his perspective was can mails stored in the pst files be tampered and if they can how would you be able to track the changes?
If anyone could help me resolve this issue would appreciate the same.
Yes it can be tempered with.
I am not sure it can be tracked within the file itself.
It is nothing special how it is written or stored, albeit it can be encrypted.
There is a
… was can mails stored in the pst files be tampered
In what way do you mean 'tampered with'?
Essentially, if you take a PST from source i.e. an exchange server, keep a pristine copy safe somewhere and work with a copy then you can always revert back to a copy of the Pristine PST should anyone have any queries regarding the data in the PST.
From my understanding a user can only 'tamper' with a PST in the following ways
1. Rename the PST
2. Modify the timestamp information
3. Delete mails from within the PST
4. Modify mails saved within the drafts folder
5. Modify/Update/Delete calendar/Note etc entries
Are these what you had in mind? If so the file system may give clues to 1 and 2. You can recover delete emails from PSTs and for 4 and 5 the proiperties entry for the event should tell you when it was last updated.
Ronan
Absolutely anything digital can potentially be tampered with if you have physical access to the system and there's not point of entry security (whole drive encryption), and even in these cases, you can still social engineer access and tamper.
In the forensics situation, this is why you duplicate, keep an original copy untouched, and document chain of custody. Before it gets into your chain of custody, anything is possible. Of course, most people either don't have the skills to try to falsify digital evidence or are sloppy such that a proper forensic examination will show discrepancies.
You can edit emails saved with a PST, even if they aren't in the draft folder. You can also export a MSG, edit it, and then re-add it to the PST.
There are several internal metadata fields which a PST stores for emails which might contain relevant information. For example there is a Modified Date field that might indicate that an email was tampered with, or a Last Author field.
From my testing, these fields are not always updated for all document types, so it depends on the specific situation, but it might yield some useful information.
There are both VB and C objects out there which can read, and write Personal Storage Tables.
I am confident there are third party (not Microsoft) products out there that can edit the messages and content, without leaving any evidence of change within the PST.
Do you actually have to demonstrate it?
Thank you for the reply but what I am looking at is as follows…
Mr A receives mails from B,C D and E….
I want to know if i can pick the contents of email from C and add it to the email of D.
If this is possible could you give me the method how it can be done or links to sites i can refer too…
Yes i need to demo this act….
Yes, this is possible.
Create a new .pst file and copy some .msg files into it.
Open an .msg file from the .pst and choose Edit > Edit Message
Type some words into the message body, or delete some text
Close and save the message
You now have a revised e-mail in a .pst file.
Information regarding potential activity of this nature will likely be stored in the Modified metadata field of the individual e-mail. Extract the date/time metadata for all e-mails in the .pst file and you will either see a lot of typical looking dates/times or something will look amiss. If you have suspect messages obviously focus on reviewing that metadata first and look for anomalies.
If you're in an Exchange environment, see if there are any backups you can look to for a more authoritative set of data, then compare. Also look for the .ost file on the local machine (if you have access to it) and parse it. I just worked on an investigation where the .ost file hadn't been updated in a while and there were a significant number of sent items that were otherwise unavailable.
Good luck.
Take a look at this reference
http//
It is a recent write up by Joachim Metz