jman0 war
asked on
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?
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?
William Fulks
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.
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.
http://blogs.technet.com/b/exchange/archive/2013/06/17/log-parser-studio-2-2-is-now-available.aspx
Since you know the compromised mailboxes, you can use Log Parser Studio to pull the data you are looking for.
http://blogs.technet.com/b/exchange/archive/2013/06/17/log-parser-studio-2-2-is-now-available.aspx
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 - http://windowsitpro.com/exchange-server-2010/mailbox-auditing-exchange-server-2010
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
http://www.msexchange.org/articles-tutorials/exchange-server-2013/compliance-policies-archiving/e-mail-forensics-corporate-exchange-environment-part1.html
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 - http://windowsitpro.com/exchange-server-2010/mailbox-auditing-exchange-server-2010
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
http://www.msexchange.org/articles-tutorials/exchange-server-2013/compliance-policies-archiving/e-mail-forensics-corporate-exchange-environment-part1.html
ASKER
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.
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.
ASKER
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?
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?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.