Does anyone know how to find the authenticated user account in Exchange 2013 that is sending emails?  We believe an account has been compromised but can't find the compromised account.  Using SMTP an email client or malware application can be setup to connect to Exchange with a valid email account and a bogus email address.   I need to find the way to associate the bogus address with the actual authentication account being used.  In older versions of Exchange you could just add the username column to the logs but Exchange 2013 does not appear to have this option. 

An example is salepersonjoe has account salespersonjoe@somedomain.com and logs in to Exchange using the domain name and password for salespersonjoe. salespersonjoe's account password has been stolen is now being used to send bogus/spam/virus email. This stolen account is then used to send email from aslkjdf1324asdf@somedomain.com using salespersonjoe's info. Exchange unfortunately will still send emails with the bogus email account when using SMTP.  There is no way to relate aslkjdf1324asdf@somedomain.com to salepersonjoe's account in the logs and I need a way or some other solution to find the hacked account.  

The emails don't end up in any sent items folder so logging into every mailbox and looking for sent items isn't going to work.. 

Using the IP address is a temporary work around but we've blocked a couple subnets entirely due to they just keep using a different IP address but want to find the compromised account.

Thanks

Enabled SMTP log? Ip address and the user will be available in the smtp log.

The ip address and the bad email address is in the log however the user is not logged.

Anonymous sending allowed?
If auditing is enabled, try to find the time in the security event log.

The server is not an open relay. It passes the mxtoolbox and change connectivity tests. Are you referring to another option that I am interpreting incorrectly?

The server is not an open relay. It passes the mxtoolbox and change connectivity tests. Are you referring to another option that I am interpreting incorrectly?

You can bump event log levels to expert for MSExchangeTransport and it should surface to the logs. Cant tell you which ones, but I would pick the obvious ones.

The server is not an open relay. It passes the mxtoolbox and Exchange connectivity tests. Are you referring to another option that I am interpreting incorrectly?

• Edited by jhersey 14 hours 28 minutes ago

The server is not an open relay. It passes the mxtoolbox and Exchange connectivity tests. Are you referring to another option that I am interpreting incorrectly?

• Edited by jhersey Monday, August 31, 2015 5:00 PM

Hi,

If there is any specific keyword for these bogus/spam/virus email, please enable and check the messages tracking logs and protocol logs to check the stolen account to have a try.

Additionally, if the stolen account can send email from aslkjdf1324asdf@somedomain.com using salespersonjoe's info successfully, please check the send as, send on behalf and mailbox full access permission for aslkjdf1324asdf@somedomain.com mailbox.

Personal suggestion, we can create a transport rule to forward all messages which are sent from aslkjdf1324asdf@somedomain.com mailbox to Administrator and check the message header for Sender information.

Regards,

Every email is about the same but has 4 variants or so and they all are sent to random email addresses ending in .com.br.  The protocol logs are on as well as the tracking logs.  These logs still do not contain the authenticated username.  I don't think people understand the question or the problem because some of the responses are in left field.  However I do appreciate the effort.  aslkjdf1324asdf@somedomain.com is not even an email address assigned to anyone, anything, any group, in the domain.  Exchange only checks the send as, send on behalf and mailbox full permissions for accounts that actually exist.  If the aslkjdf1324asdf is replaced with any random numbers and letter and that combination is not assigned to a user exchange will send the email using SMTP with out checking any send as, send on behalf of, etc. It is clearly a flaw in Exchange's SMTP send connector.  It simply should not send email from email addresses that aren't assigned to a user, distribution group, etc.

This is not an open relay so don't confuse that. 

Please setup your email account in an SMTP client.  Get it working using your real account info then simply change your email address in the settings to anyrandomlettersthatarenotarealemailaddress@yourdomain.com. You will see that Exchange will send the email.  It authenticates with your domain credentials, they are not logged and then it will just send the email and only log the anyrandomlettersthatarenotarealemailaddress@yourdomain.com.

If you haven't done this to test I'm pretty sure you don't understand they question and are thinking too much about how Exchange is supposed to and not how it is working.

• Edited by jhersey 6 hours 40 minutes ago

Every email is about the same but has 4 variants or so and they all are sent to random email addresses ending in .com.br.  The protocol logs are on as well as the tracking logs.  These logs still do not contain the authenticated username.  I don't think people understand the question or the problem because some of the responses are in left field.  However I do appreciate the effort.  aslkjdf1324asdf@somedomain.com is not even an email address assigned to anyone, anything, any group, in the domain.  Exchange only checks the send as, send on behalf and mailbox full permissions for accounts that actually exist.  If the aslkjdf1324asdf is replaced with any random numbers and letter and that combination is not assigned to a user exchange will send the email using SMTP with out checking any send as, send on behalf of, etc. It is clearly a flaw in Exchange's SMTP send connector.  It simply should not send email from email addresses that aren't assigned to a user, distribution group, etc.

This is not an open relay so don't confuse that. 

Please setup your email account in an SMTP client.  Get it working using your real account info then simply change your email address in the settings to anyrandomlettersthatarenotarealemailaddress@yourdomain.com. You will see that Exchange will send the email.  It authenticates with your domain credentials, they are not logged and then it will just send the email and only log the anyrandomlettersthatarenotarealemailaddress@yourdomain.com.

If you haven't done this to test I'm pretty sure you don't understand the question and are thinking too much about how Exchange is supposed to and not how it is working.

• Edited by jhersey 14 hours 26 minutes ago

Every email is about the same but has 4 variants or so and they all are sent to random email addresses ending in .com.br.  The protocol logs are on as well as the tracking logs.  These logs still do not contain the authenticated username.  I don't think people understand the question or the problem because some of the responses are in left field.  However I do appreciate the effort.  aslkjdf1324asdf@somedomain.com is not even an email address assigned to anyone, anything, any group, in the domain.  Exchange only checks the send as, send on behalf and mailbox full permissions for accounts that actually exist.  If the aslkjdf1324asdf is replaced with any random numbers and letter and that combination is not assigned to a user exchange will send the email using SMTP with out checking any send as, send on behalf of, etc. It is clearly a flaw in Exchange's SMTP send connector.  It simply should not send email from email addresses that aren't assigned to a user, distribution group, etc.

This is not an open relay so don't confuse that. 

Please setup your email account in an SMTP client.  Get it working using your real account info then simply change your email address in the settings to anyrandomlettersthatarenotarealemailaddress@yourdomain.com. You will see that Exchange will send the email.  It authenticates with your domain credentials, they are not logged and then it will just send the email and only log the anyrandomlettersthatarenotarealemailaddress@yourdomain.com.

If you haven't done this to test I'm pretty sure you don't understand the question and are thinking too much about how Exchange is supposed to and not how it is working.

• Edited by jhersey Monday, August 31, 2015 5:03 PM

Example for you :)

Get-TransportServer | Get-MessageTrackingLog -Start "08/31/2015 00:00:00" -End "08/31/2015 23:59:00"-Sender "fkwjbfksdjb@jscnsdkcjn.com" -resultsize unlimited | fl OriginalClientIp

Getting the client IP does not return the user account. The sending client ip address is not from any of our locations.  I can easily open any off the logs and search for .com.br and find many of the emails and the client's IP but not the user account that has been compromised.

We've had to block many IP addresses at the firewall and none of them belong to one of our remote locations.  When we block one IP addresses with in a few hours they will start doing it again from another IP address.  The same Spanish messages going to random addresses in .com.br.

What I would give for the logs to show the authenticated user account.

REAL SAMPLE (with minor changes to hide the server)

#Fields: date-time,client-ip,client-hostname,server-ip,server-hostname,source-context,connector-id,source,event-id,internal-message-id,message-id,network-message-id,recipient-address,recipient-status,total-bytes,recipient-count,related-recipient-address,reference,message-subject,sender-address,return-path,message-info,directionality,tenant-id,original-client-ip,original-server-ip,custom-data

2015-08-26T15:00:01.507Z,,SERVER1,,,,,AGENT,AGENTINFO,64424509813,<24e096fd25f746aea6de89c3c78f04ff@SERVER1.DOMAIN.local>,f29b0167-977b-44dc-9d88-08d2ae23e045,baiocchi2@netgo.com.br,,8560,1,,,Disfuncao eretil e ejaculacao precoce tem Tratamento! Ja ajudamos mais de 1 milhao de homens em todo mundo.,ogbpi6j@somedomain.com,ogbpi6j@somedomain.com,,Incoming,,5.196.240.169,xxx.xxx.xxx.xxx,S:CompCost=|ETR=0;S:DeliveryPriority=Normal;S:AccountForest=DOMAIN.local

Is forcing users to change password an option (if this is becoming a real problem)?

That would prevent the account from being used with the old (no longer valid) password.

You might also be able to audit failed logon attempts if someone tries to still use the old password.

We did resort to requiring every user to change their password.  Getting over 90 seats to change their passwords was a disappointing solution.  Lots of users use Outlook and it doesn't force the password change box up. We have to direct them to the OWA site and then they can change their passwords.  The users are mostly all disconnected over the network in many locations. 

I am still hoping that someone can answer the original question which quite baffles me that this can not be done in Exchange.

You can go or send another engineer to your computer by ip address and examine.
The username may be registered in the event log (Security), you were watching the event log?

I'm not sure what suggesting.  I can not go into another computer that isn't owned be my company.  Well I suppose I could try to hack into it but.....  We did turn on Security logging but didn't see anything consistent enough.  There appears to be quite a bit of caching of the authentication and each time the hacked account sent an email the system did not log a login event.