Spam Attack - Exchange 2010
Greetings,
A few days ago, we had an email attack that resulted in hundreds of emails being sent (or attempted to be sent) through our Exchange 2010 server and our ZixGateway secure email appliance. Fortunately, most emails appear to have been held in queue on your Zix appliance, preventing delivery and allowing us to avoid being blacklisted. Unfortunately, I'm the only network admin and I was on PTO at the time of the attack. Even more unfortunate, my company has yet to approve any syslog solution, much less a SIEM product. So, information available to me is somewhat limited. The thing that seem to stop the attack was changing the network password of the impacted user. This really concerns me, as the user is a domain admin. Anyhow, in the Exchange logs, I have found several examples similar to the following:
2017-04-20T15:42:25.101Z,1
2017-04-20T15:42:25.164Z,1
2017-04-20T15:42:26.428Z,1
2017-04-20T15:42:26.490Z,1
2017-04-20T15:42:27.754Z,1
2017-04-20T15:42:27.816Z,1
What I'm trying to figure out is the method of the attack and the source. We don't allow relaying. I have very limited firewall (SonicWALL router) logs and no Security logs from any server. I suspect that this is a relaying attack (from several IP addresses), but it could also be a compromised device within our network. Unfortunately, without Security logs, it seems pretty tough to confirm much.
As such, I'm hoping that someone out there can help shed some light on what I should do and look for. I'm not comfortable at all with simply changing a password.
I appreciate any assistance.
Thank you,
Jeremy
A few days ago, we had an email attack that resulted in hundreds of emails being sent (or attempted to be sent) through our Exchange 2010 server and our ZixGateway secure email appliance. Fortunately, most emails appear to have been held in queue on your Zix appliance, preventing delivery and allowing us to avoid being blacklisted. Unfortunately, I'm the only network admin and I was on PTO at the time of the attack. Even more unfortunate, my company has yet to approve any syslog solution, much less a SIEM product. So, information available to me is somewhat limited. The thing that seem to stop the attack was changing the network password of the impacted user. This really concerns me, as the user is a domain admin. Anyhow, in the Exchange logs, I have found several examples similar to the following:
2017-04-20T15:42:25.101Z,1
2017-04-20T15:42:25.164Z,1
2017-04-20T15:42:26.428Z,1
2017-04-20T15:42:26.490Z,1
2017-04-20T15:42:27.754Z,1
2017-04-20T15:42:27.816Z,1
What I'm trying to figure out is the method of the attack and the source. We don't allow relaying. I have very limited firewall (SonicWALL router) logs and no Security logs from any server. I suspect that this is a relaying attack (from several IP addresses), but it could also be a compromised device within our network. Unfortunately, without Security logs, it seems pretty tough to confirm much.
As such, I'm hoping that someone out there can help shed some light on what I should do and look for. I'm not comfortable at all with simply changing a password.
I appreciate any assistance.
Thank you,
Jeremy
ASKER
The 192.168.1.x addresses listed are my email server and the smart host. I've checked for incoming SMTP traffic and haven't seen anything out of the ordinary. All legit machines have updated AV. With the password change, I'd have expected to see lockouts or failed logins on my DCs and my Exchange server. I don't see any of that. Granted, it may have been there on April 20th, but there hasn't been anything since I started looking into it (April 25).
Jeremy
Jeremy
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
If a user account has their credentials compromised, authenticated relay is a possibility, even if you don't allow anonymous relay. Exchange includes an Authenticated SMTP relay connector that uses port 587 to send email. This is provided so users can send email when using IMAP or POP3. If you don't have any users that use either of those, you can disable the receive connector that allows authenticated relay to prevent this type of attack from succeeding. Just look through your Exchange servers' receive connectors and disable/delete any that are running on port 587 and authenticated relay will be disabled. Not, also, that if you do this network devices won't be able to use Exchange for SMTP relaying in any way. You may still have SMTP logs for that connector that could help you determine if this is what happened, though, since that connector isn't regularly used, most of the time.
As an aside, if you need to use Exchange to allow network devices to send email to internal users only, you can use the "Direct send" method, which involves sending unauthenticated mail on port 25 to the Exchange server. You can only send to internal users with this method, and you have to allow it through any spam filters/connection filters you have set up in Exchange.
As an aside, if you need to use Exchange to allow network devices to send email to internal users only, you can use the "Direct send" method, which involves sending unauthenticated mail on port 25 to the Exchange server. You can only send to internal users with this method, and you have to allow it through any spam filters/connection filters you have set up in Exchange.
The thing that seem to stop the attack was changing the network password of the impacted user. This really concerns me, as the user is a domain admin.
That tells me that this was most likely through webmail. However, if there is RDP access to the person's computer, that is the other possibility.
I would make 3 suggestions:
1) Review the password complexity rules in your domain
2) Consider creating separate admin accounts for those who do admin work. That way, you'll know that there is a separation, and that users should not be using them for regular things.
3) Review remote access mechanisms
ASKER
Thanks for all the responses. There were no traces of the emails in the users Sent Items. She actually was receiving the rejection emails from our smart host, which allowed her to know that something was wrong. We do have solid complexity rules for passwords. Of course, that doesn't mean they can't be identified. We're actually working to separate admin accounts from the actual users, limiting risk and impact. I'll need to check into my receive connectors more, regarding port 587. Off the top of my head, it seems like we need that for our Zix email environment, but I could be wrong, Definitely gives me something to research.
Thanks,
Jeremy
Thanks,
Jeremy
Do you have any sort of message headers? The messages had to come to the smart host from somewhere. Besides, if someone is going to use someone else's account to send email, they're not really going to leave traces in the Sent folder (that's a dead giveaway). If you use the Exchange console, are you able to do any message tracking?
ASKER
The header info of the rejection messages didn't appear to be anymore informational than the messagetracking logs listed above. Here is an example (the internal "from" address is not valid in our environment":
Delivery has failed to these recipients or groups:
iburge@cogeco.ca
A problem occurred during the delivery of this message to this e-mail address. Try sending this message again. If the problem continues, please contact your helpdesk.
The following organization rejected your message: mx.cogeco.ca.
Diagnostic information for administrators:
Generating server: Smarthost01.domain1.com
iburge@cogeco.ca
mx.cogeco.ca #<mx.cogeco.ca #5.0.0 smtp; 550 #5.1.0 Address rejected.> #SMTP#
Original message headers:
Return-Path: <user1@domain1.com>
Received: from 127.0.0.1 (ZixVPM [127.0.0.1])
by Outbound.domain1.com (Proprietary) with SMTP id CBE31301FFA
for <iburge@cogeco.ca>; Thu, 20 Apr 2017 10:29:51 -0500 (CDT)
Received: by Smarthost01.domain1.com (Proprietary, from userid 89)
id B6AF6301F12; Thu, 20 Apr 2017 10:29:01 -0500 (CDT)
Received: from 127.0.0.1 (ZixVPM [127.0.0.1])
by Outbound.domain1.com (Proprietary) with SMTP id B8A64301FFA
for <iburge@cogeco.ca>; Thu, 20 Apr 2017 10:28:13 -0500 (CDT)
Received: from EmailServer01.domain1.com (smtp.domain1.com [192.168.1.129])
(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by Smarthost01.domain1.com (Proprietary) with ESMTPS id 6F568301E77
for <iburge@cogeco.ca>; Thu, 20 Apr 2017 10:28:13 -0500 (CDT)
Received: from [10.0.0.4] (78.20.85.83) by mail.domain1.com
(192.168.1.125) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 20 Apr
2017 10:28:13 -0500
Message-ID: <366809D9612E2FDA7A50F6FEA
Reply-To: Andre Williams <hiring@recruitment-cf.com
From: Andre Williams <user1@domain1.com>
To: <iburge@cogeco.ca>
Subject: new post available: insurance claims executive
Date: Thu, 20 Apr 2017 16:15:57 -0700
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 16.4.3505.912
X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912
Content-Transfer-Encoding:
X-TM-AS-Product-Ver: SMEX-12.0.0.1350-8.100.106
X-TM-AS-Result: Yes-26.002300-5.000000-31
X-TM-AS-MatchedID: 702020-121132-700752-86049
00927-707997-702762-701229
-704775-703223-700445-7011
96-703829-703788-113898-70
8004-148133-148149-148151-
X-TM-AS-User-Approved-Send
X-TM-AS-User-Blocked-Sende
X-VPM-MSG-ID: f9175af3-1f67-488b-af75-99
X-VPM-HOST: Smarthost01.domain1.com
X-VPM-GROUP-ID: 858ca9f8-67ae-4028-af93-21
X-VPM-ENC-REGIME: TLS,Plaintext
X-VPM-IS-HYBRID: 0
CC:
Delivery has failed to these recipients or groups:
iburge@cogeco.ca
A problem occurred during the delivery of this message to this e-mail address. Try sending this message again. If the problem continues, please contact your helpdesk.
The following organization rejected your message: mx.cogeco.ca.
Diagnostic information for administrators:
Generating server: Smarthost01.domain1.com
iburge@cogeco.ca
mx.cogeco.ca #<mx.cogeco.ca #5.0.0 smtp; 550 #5.1.0 Address rejected.> #SMTP#
Original message headers:
Return-Path: <user1@domain1.com>
Received: from 127.0.0.1 (ZixVPM [127.0.0.1])
by Outbound.domain1.com (Proprietary) with SMTP id CBE31301FFA
for <iburge@cogeco.ca>; Thu, 20 Apr 2017 10:29:51 -0500 (CDT)
Received: by Smarthost01.domain1.com (Proprietary, from userid 89)
id B6AF6301F12; Thu, 20 Apr 2017 10:29:01 -0500 (CDT)
Received: from 127.0.0.1 (ZixVPM [127.0.0.1])
by Outbound.domain1.com (Proprietary) with SMTP id B8A64301FFA
for <iburge@cogeco.ca>; Thu, 20 Apr 2017 10:28:13 -0500 (CDT)
Received: from EmailServer01.domain1.com (smtp.domain1.com [192.168.1.129])
(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by Smarthost01.domain1.com (Proprietary) with ESMTPS id 6F568301E77
for <iburge@cogeco.ca>; Thu, 20 Apr 2017 10:28:13 -0500 (CDT)
Received: from [10.0.0.4] (78.20.85.83) by mail.domain1.com
(192.168.1.125) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 20 Apr
2017 10:28:13 -0500
Message-ID: <366809D9612E2FDA7A50F6FEA
Reply-To: Andre Williams <hiring@recruitment-cf.com
From: Andre Williams <user1@domain1.com>
To: <iburge@cogeco.ca>
Subject: new post available: insurance claims executive
Date: Thu, 20 Apr 2017 16:15:57 -0700
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 16.4.3505.912
X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912
Content-Transfer-Encoding:
X-TM-AS-Product-Ver: SMEX-12.0.0.1350-8.100.106
X-TM-AS-Result: Yes-26.002300-5.000000-31
X-TM-AS-MatchedID: 702020-121132-700752-86049
00927-707997-702762-701229
-704775-703223-700445-7011
96-703829-703788-113898-70
8004-148133-148149-148151-
X-TM-AS-User-Approved-Send
X-TM-AS-User-Blocked-Sende
X-VPM-MSG-ID: f9175af3-1f67-488b-af75-99
X-VPM-HOST: Smarthost01.domain1.com
X-VPM-GROUP-ID: 858ca9f8-67ae-4028-af93-21
X-VPM-ENC-REGIME: TLS,Plaintext
X-VPM-IS-HYBRID: 0
CC:
I was wondering about this earlier. Is it possible the original messages did not come from your domain? The spammer is impersonating your user. Thus if they send to an address that doesn't exist, the NDR notices comes to your server.
That kind of error occurs because the recipient server (mx.cogeco.ca in your example) is not checking to see if the sender is authorized to send as your domain.
Normally this is prevented by the mail gateway checking to see if the address exists *before* accepting the message. If it rejects the message due to an incorrect address then it's up to the senders server to inform the sender. Thus the message never gets to your mail server.
That kind of error occurs because the recipient server (mx.cogeco.ca in your example) is not checking to see if the sender is authorized to send as your domain.
Normally this is prevented by the mail gateway checking to see if the address exists *before* accepting the message. If it rejects the message due to an incorrect address then it's up to the senders server to inform the sender. Thus the message never gets to your mail server.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Our smart host held the emails in queue, so they definitely originated from my Exchange server. I've gone through the EMC and every log file on the Exchange server. What I've posted is all that I have found to be pertinent. I do have a Client Receive Connector that uses port 587 for all addresses with the only permission group of Exchange users. If I'm understanding correctly, I need that, as we only have one Exchange server serving all roles (we don't have a separate Edge server).
Do you have cause for usage of connecting to the server through anything other than Outlook or webmail?
And how many receive connectors are running?
And how many receive connectors are running?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Well, while there wasn't necessarily a solution here, as I didn't have the logs that I needed to get more information, there was good information provided by the experts for me to look into.
Easiest way to tell is check your outside firewall for inbound SMTP traffic (port 25).