locked
SBS 2003 Probably infected RRS feed

  • Question

  • Have a customer whose SBS 2003 (fully patched) box is almost certainly infected.  SMTP Relay is disabled yet tons of NDRs in the Application Event Log.  Have a rule in the SonicWALL to only allow SMTP port 25 from the SBS2003 server IP.  The NDRs are all over the place, 5.4.0, 5.1.8, 5.2.0, etc.  Some suggest looping due to multiple Virtual SMTP servers.  We have one. Others suggest DNS issues.  Nslookup confirms DNS is configured correctly to send email.

    Below is a logging sample.  All the IPs are public so presumable comming from the Internet.  Our server name is SERVER.

    So is SBS2003 relaying due to an infections or ???

    Thanks in advance!
    John

    #Software: Microsoft Internet Information Services 6.0
    #Version: 1.0
    #Date: 2014-01-04 17:00:06
    #Fields:      date time   c-ip                       cs-username                            s-sitename   s-computername  s-ip  s-port
    2014-01-04 17:00:06   207.155.249.186   OutboundConnectionResponse   SMTPSVC1    SERVER               -      25

    2014-01-04 17:00:06 207.155.249.186 OutboundConnectionCommand SMTPSVC1 SERVER - 25
    2014-01-04 17:00:06 207.155.249.186 OutboundConnectionResponse SMTPSVC1 SERVER - 25
    2014-01-04 17:00:06 64.90.206.132 OutboundConnectionResponse SMTPSVC1 SERVER - 25
    2014-01-04 17:00:06 64.90.206.132 OutboundConnectionCommand SMTPSVC1 SERVER - 25

    Saturday, January 4, 2014 6:26 PM

All replies

  • Post one NDR and event in application log.

    Cheers,

    Gulab Prasad,

    Technology Consultant

    Blog: www.exchangeranger.com  Twitter:    LinkedIn:   
    Check out CodeTwo’s tools for Exchange admins   

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Saturday, January 4, 2014 7:42 PM
  • Below are the different NDR notices in the event log.  We do not see the actual NDRs themselves.  Our mail eventually goes out but ut takes a while.  Also more evidence of infection... Administrator cannot install anything.  Can't create temp files.  In the temp folder I can create a folder but get access denied if I try o delete it.  Permissions show Admin has full control.

    Event Type: Error
    Event Source: MSExchangeTransport
    Event Category: NDR
    Event ID: 3030
    Date:  1/4/2014
    Time:  10:48:50 AM
    User:  N/A
    Computer: SERVER
    Description:
    A non-delivery report with a status code of 4.7.1 was generated for recipient rfc822;aizurra@bankislam.com.my (Message-ID <SERVERzb8vq3UhQCAIx000004c3@wvpmg.com>).

    Event Type: Error
    Event Source: MSExchangeTransport
    Event Category: NDR
    Event ID: 3018
    Date:  1/4/2014
    Time:  10:27:23 AM
    User:  N/A
    Computer: SERVER
    Description:
    A non-delivery report with a status code of 5.4.0 was generated for recipient rfc822;barb@mydoubleagents.com (Message-ID <SERVERnzwjyXSz9qGFT00001399@wvpmg.com>).  
    Causes: This message indicates a DNS problem or an IP address configuration problem  
    Solution: Check the DNS using nslookup or dnsq. Verify the IP address is in IPv4 literal format.
    For more information, click http://www.microsoft.com/contentredirect.asp.
    Data:
    0000: ef 02 04 c0               ï..À  

     

    Event Type: Error
    Event Source: MSExchangeTransport
    Event Category: NDR
    Event ID: 3015
    Date:  1/4/2014
    Time:  10:27:01 AM
    User:  N/A
    Computer: SERVER
    Description:
    A non-delivery report with a status code of 5.3.0 was generated for recipient rfc822;barb@changdentalcenter.com (Message-ID <SERVERnzwjyXSz9qGFT00001399@wvpmg.com>).  
    Causes: Exchange mistakenly attempted mail delivery to an incorrect MTA route. 
    For more information, click http://www.microsoft.com/contentredirect.asp.   
    Solution: Check your route and topology; use the winroute tool to ensure the routes are properly replicated between servers and routing groups.

    Event Type: Error
    Event Source: MSExchangeTransport
    Event Category: NDR
    Event ID: 3008
    Date:  1/4/2014
    Time:  10:26:41 AM
    User:  N/A
    Computer: SERVER
    Description:
    A non-delivery report with a status code of 5.0.0 was generated for recipient rfc822;bar@bootleggersbar.com (Message-ID <SERVER6BJ8QiIWMzRsf0000139b@wvpmg.com>).  
    Cause:  This indicates a permanent failure. Possible causes :  1)No route is defined for a given address space. For example, an SMTP connector is configured, but this recipient address does not match the address spaces for which it routes mail.  2)Domain Name Server (DNS) returned an authoritative host not found for the domain.  3)The routing group does not have a connector defined û mail from one server in the routing group has no way to get to another routing group.   
    Solution: Verify that this error is not caused by a DNS lookup problem, and then check the address spaces configured on your STMP connectors. If you are delivering Internet mail through an SMTP connector,  consider adding an address space of type SMTP with value ô*ö (an asterisk) to one of the SMTP connectors to make routing possible. Verify all routing groups are connected to each other through a routing group connector or another connector.

    Event Type: Error
    Event Source: MSExchangeTransport
    Event Category: NDR
    Event ID: 3017
    Date:  1/4/2014
    Time:  10:25:13 AM
    User:  N/A
    Computer: SERVER
    Description:
    A non-delivery report with a status code of 5.3.5 was generated for recipient rfc822;pcs@avana.net (Message-ID <SERVERaatao8KK8ZtP0000016ac@wvpmg.com>).  
    Causes: A looping condition was detected. (The server is configured to route mail back to itself). If you have multiple SMTP Virtual Servers configured on your Exchange server, make sure they are defined by a unique incoming port and that the outgoing SMTP port configuration is valid to avoid looping between local virtual servers.   
    Solution: Check the configuration of the virtual serverÆs connectors for loops and ensure each virtual server is defined by a unique incoming port.

    For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
    Data:
    0000: cf 02 04 c0               Ï..À   

    Saturday, January 4, 2014 7:51 PM
  • This might be Virus issue.
    Did you scan the server and all the machine in the domain for the virus?

    We need the NDR for more specific information.
    You get NDR when you try to send email out? 


    Cheers,

    Gulab Prasad,

    Technology Consultant

    Blog: www.exchangeranger.com  Twitter:    LinkedIn:   
    Check out CodeTwo’s tools for Exchange admins   

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Saturday, January 4, 2014 8:07 PM
  • I am pretty sure it is a virus or a bot or whatever.  Scanned the workstations with the Kaspersky Virus Removal Tool, clean.  Scanned the server with same, clean.  Tried to scan the server with Malwarebytes but cannot install it as mentioned previously.

    John

    Sunday, January 5, 2014 3:53 PM
  • For the SMTP protocol log to be of any use you'll have to record more columns of data. I'd just check ALL the boxes on the "Advanced" tab of the log file's properties.

    The fact that the IP addresses are different and all on the Internet is to be expected (they're all "outbound") and doesn't mean that you've completely disabled SMTP relays. That's especially true if you all authenticated clients to relay. You may just have an account whose password has been cracked.

    If a cracked account is being used you'll find the AUTH commands in the SMTP protocol log (after you modify it to record that information). If you find them you'll also find the base64-encoded user name and password in the log file. Decode the user name and either disable that account or change its password to something strong.

    Is it safe to assume that you don't accept any e-mails sent to addresses that aren't in your directory? IOW, you've enabled recipient filtering on the SMTO virtual server used to receive e-mail from the Internet, correct?


    --- Rich Matheisen MCSE&I, Exchange MVP

    Sunday, January 5, 2014 8:34 PM
  • Found 6 AUTH commands is a 1000Kb log file.  Sample below.  The string after the AUTH=<> is 0040 in all but one.
     2014-01-05 21:56:45 204.197.210.117 OutboundConnectionCommand SMTPSVC1 SERVER - 25 MAIL - FROM:<<a href="mailto:adinfo@tengergroup.com>+AUTH">adinfo@tengergroup.com>+AUTH=<> 0 0 4 0 172 SMTP - - - -

    Relay Restrictions are Only IPs List Below, Only IP of the server and 127.0.0.1 of course.  Allow all computers which successfully authenticate to relay, ... is UNCHECKED.  Authenticated Users can submit but not relay.

    As for accepting emails sent to addresses not in the directory...  If that is the SBS2003 default and I assume it is then no.

    As for "you've enabled recipient filtering on the SMTO virtual server used to receive e-mail from the Internet"  I don't know.  Not sure where this is.  Assuming you meant SMTP and not SMTO I do not see a recipient filtering option in any of the properties for the SMTP virtual server.

    John

    Sunday, January 5, 2014 10:06 PM
  • So the example shows the sender to be adinfo@tengergroup.com. Is that your domain? Is that an address you'd expect to be sending email? Is 204.197.210.117 an address that the sender would normally be sending e-mail to?

    What you've found in the log is only half (the sending half) of the information. If your server's being used as a SMTP relay then you should find a corresponding conversation with the sender while that message was being received. It's the receiving part that will reveal the origin of the message.

    I can't answer your question about what SBS uses as defaults. Nor can I tell you whether SBS has some wizard that must be used to change settings (it usually does). But if you want to check to see if recipient filtering is enabled, first "Global Settings | Message Delivery" object and select the "Recipient Filtering" tab. Is the "Filter recipients who are not in the Directory" box checked? If not, check it. Then open the property page for the SMTP virtual server and, on the "General" tab, click the "Advanced" button. Select the line appropriate to the IP address and click the "Edit" button. Is the "Apply Recipient Filter" box checked? If not, check it. At that point any e-mail addressed to an unknown address in your domain will be rejected. Your server will no longer be responsible for sending NDRs to external recipients for badly addresses e-mail.


    --- Rich Matheisen MCSE&I, Exchange MVP

    Monday, January 6, 2014 4:28 AM
  • Tengergroup.com is not our domain and we would not expect to be getting email from that domain.

    204.197.210.117 is not connected to us in any way.

    Filter recipients who are not in the Directory is checked.

    Apply Recipient Filter box is also checked.

    Monday, January 6, 2014 9:21 PM
  • Hi,

    I recommend you check if the smtp relay is disabled in SBS 2003. You can follow the following article.

    How to block open SMTP relaying and clean up Exchange Server SMTP queues in Windows Small Business Server
    http://support.microsoft.com/default.aspx?scid=kb;EN-US;324958

    Best regards,
    Belinda


    Belinda Ma
    TechNet Community Support

    Tuesday, January 7, 2014 3:18 AM
  • If it's a message being sent from a SMTP client there'll be a record of the INBOUND message in the SMTP protocol log. Did you find it? Does the source IP address belong in your LAN?

    If the message originated from a MAPI/RPC client, or from an OWA client, there'll be a record of it in the message tracking log. Unfortunately it won't identify the source, but it'd be unusual that one of those client types would be able to forge the sender address.

    BTW, if you have only a single Exchange server there's no reason why it's IP addresses should be allowed to relay. Unless you have something running on the server that uses anonymous SMTP to send e-mail out of your organization, I'd remove ALL the IP addresses from the "allowed to relay" list.


    --- Rich Matheisen MCSE&I, Exchange MVP

    Tuesday, January 7, 2014 3:21 AM
  • Just going to wipe it and reload SBS2003.
    Tuesday, January 7, 2014 10:02 PM
  • That's one way of prolonging the troubleshooting. :-)

    If you set it up the same way it is now that's not going to solve anything. And if you don't know what the source of the problem is you'll just be starting over -- maybe with a new set of problems!


    --- Rich Matheisen MCSE&I, Exchange MVP

    Tuesday, January 7, 2014 10:13 PM
  • What you don't know is this server worked flawlessly since December 2007.  Then one day X number of days ago it suddenly appeared like the original setup had not been completed.  Complete with the "Continue Setup" icon on the desktop.  It was useless as anything other than a file and print server until Continue Setup was run.  After that the fun began.

    Regards,

    John

    Tuesday, January 7, 2014 10:20 PM
  • Lovely that you put that in your original problem description! You would have immediately been referred to the SBS forums for help.

    --- Rich Matheisen MCSE&I, Exchange MVP

    Tuesday, January 7, 2014 10:30 PM