Email forensics?

We had a successful phishing attempt whereby a couple users were tricked into clicking a link in an email and giving their username and passwords.
Really silly i know.

I can see on our Exchange CAS servers that the phisher then logged in via OWA.
Those compromised mailboxes started spewing out spam.
That's how the problem got noticed.

Our Security department wants to know if protected customer information was accessed in the compromised mailboxes.
I really have no way to determine that.
Like, if an email was Read, or if an attachment was opened..

Our OWA is setup so that it presents a choice of  Public Computer or Private Computer at logon.
If Public Computer is chosen then file attachments are blocked.

So would there be anyway to determine if the attacker came in on the  Public or Private option?

Upstream of our CAS servers are a couple Forefront TMG servers.
But i'm not finding much of use in Reports on the TMG servers.

Also does anyone know of a company that would be able to perform a forensics analysis of this incident?
jman0 warAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

William FulksSystems Analyst & WebmasterCommented:
There is a feature in Exchange called Mailbox Audit Logging but I don't know if it will do you much good if it was turned off. You may want to look into that at least for future security concerns.
Scott CSenior EngineerCommented:
You can try looking at the IIS logs to see if you can tell which way the attackers came in.  As they were coming in through OWA all connections should have been logged through IIS.

Since you know the compromised mailboxes, you can use Log Parser Studio to pull the data you are looking for.
btanExec ConsultantCommented:
Actually not a silly thing and in fact, you are doing good to the user and whole organisation.

For the exchange investigation, it really comes down to audit trail been enabled rather than just based on time stamp from the FW or proxy fronting the exchange server. The accuracy comes from the system itself governing these access and privileges.

For example, mailbox auditing in exchange 2010 and later can have auditing configurable on an individual mailbox basis rather than for a complete server. This value add for you to state those compromised inbox per se. The exchange 2010 and later versions store mailbox audit items in a hidden Audits subfolder in the Recoverable Items folder in the user's mailbox. No client can see the items in the Audits subfolder because it's hidden by Exchange. However, if you really want to, you can use a program such as MFCMAPI to see what the items look like.

Furthermore, you can see the MSDN describes administrator able to go into enabling three levels of access such as user, delegate, and administrative as well as audit up to many (if I recall is eleven or so) different actions, includes create and update etc. This adds on to your need on action done to those inboxes of interest.

A good primer sums it up -

However, likely the trail is not enabled at this juncture or even you may be having legacy  version prior to exchange 2010 which will not provide a full range of compliance capabilities like above mentioned granularity. The Managed Folders or Journaling may not be enough to perform basic audits which you are actually looking out for more..maybe the means to look at is via the standard email header in those email received and send out via that inbox to verify the source. Those IP can be checked via robtex or domain dossier, such that private IP will be more of internal workstation sending over.

As a whole (and) unfortunately the possible scenarios of misuse of an Exchange environment, both from a user and from an administrator perspective, are endless. This series did shows good step through for investigation and include litigation hold for complying ediscovery needs too. May be worth checking
How do you know if your security is working?

Protecting your business doesn’t have to mean sifting through endless alerts and notifications. With WatchGuard Total Security Suite, you can feel confident that your business is secure, meaning you can get back to the things that have been sitting on your to-do list.

jman0 warAuthor Commented:
Thanks but certainly mailbox auditing is not enabled.

Yes we know that the mailbox was accessed from another country.
Just don't know if they accessed protected information therein, or if they just used the mailbox to send out spam.

It's probably the later but it seems Security best practices indicate that the worst must be assumed to be true.
jman0 warAuthor Commented:
I spoke to another guy about IIS logs and he thought that the Public/Private option would set a cookie on the client side.

However OWA the web app must be able to interpret those cookies, so maybe there's some evidence there.

So again i wonder are there other logs that the webapp might store about the Public/Private option?
btanExec ConsultantCommented:
OWA is indeed using iis.

Not so sure about the cookie as I see it more analytics rather than hunting..and cookie is mostly for login which have it to store encrypted credential. The public and private is more of the "public or shared computer" option for owa login. It may make sense if the attacker login to ascertain he does come in but nothing more - the auto timeout is just to may make the attacker attempt more time to login ...
The cookie time-out is set based on the user's choice of either the This is a public or shared computer option or the This is a private computer option on the Outlook Web App sign-in page. By default, the cookie on the computer expires automatically and the user is signed out after they haven't used Outlook Web App for between 15 and 22.5 minutes if they've selected the public computer option, and after they haven't used Outlook Web App for between eight and twelve hours if they've selected the private computer option.

Although automatic time-out greatly reduces the risk of unauthorized access, it doesn't completely eliminate the possibility that an unauthorized user might access an Exchange mailbox if a session is left running on a public computer. Therefore, make sure that you warn users to take precautions to avoid risks, such as by telling them to sign out from Outlook Web App and close the Web browser after they've finished using Outlook Web App.

You can use MS logparser to extract the relevant information from your IIS logs. E.g found in C:\inetpub\logs\LogFiles\W3SVC1 and have all the log files merged and eventually convert to csv to check for the access... Like an example stated in

- logparser.exe -i:iisw3c “select * into c:\log\mergedlog\merge.log from c:\log\*” -o:csv
- LogParser -i:csv “SELECT cs-username, date, time, c-ip, cs-uri-stem, cs(User-Agent) FROM C:\log\mergedlog\merge.log TO C:\log\Output.csv WHERE cs-method LIKE ‘%get%’ and cs-uri-stem LIKE ‘%owa%

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Digital Forensics

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.