Recently the number of times that I received this question increased (not sure why), but the fact of the matter is that you can do something to resolve this problem (or at least identify the source of the problem), if you have the right tools. When your ISP informs you that you are in an email blacklist you can review the results by going to a site that provides real time blacklist results, such as http://www.mxtoolbox.com/blacklists.aspx.
2. Step 1 – Identifying
Next thing to do is identify the source of the problem, why your company got blacklisted? If you have ISA Server in the border of your network, what you can do is just watch your live logging creating a filter for SMTP Protocol coming from the internal network, as shown below:
If you have only one SMTP Server internally, then the only IP that you should see sending SMTP traffic is your SMTP server, if you start to see workstation’s IP address in the list then you need to investigate that further. Make sure to also get a netmon trace on ISA (internal and external adapter) at the same time or simple get an ISA Data Packager in repro mode using Web Proxy and Web Publishing template.
2. Step 2 – Containing
To contain the amount of SMTP traffic leaving your network you need to make sure that the only host that is capable to send SMTP traffic out (to the Internet) is your SMTP Server.
This is the reason why I get disappointed when I open a Firewall Policy rule and see a rule that allows All Outbound. If your environment doesn’t have such rule, the SMTP traffic that are not coming from the SMTP Server will not be able to leave your internal network in the first place.
Notice that I’m using step two as contention because on step one you are logging the real traffic, which means that you will have real data to analyze it later.
3. Step 3 – Remediating
After implementing this contention, you can now start working on the workstation and verify why it is sending traffic out to the Internet. At this point, you can:
· Get a netmon sample of the traffic, so you can see which process is sending out SMTP traffic.
· Unplug this workstation from the network
· Use an Antivirus (like Forefront Client Security or Microsoft Security Essentials) to scan the local workstation and see if it is infected.
After cleaning the system (last time that I worked in a case similar to this one, the piece of malware that was found in the workstation was Backdoor:Win32/Oderoor.gen!A.), one other thing that you can also do is to follow the procedures form the article Capturing a Trace at Boot Up and get a sample capture while the machine is starting up. With that you can see the traffic profile and make sure that there is no malicious attempt to go out right in the beginning of the system boot.
This is only a simple example of an incident response in case your SMTP is being blacklisted due a piece of malware that is running inside your network. A full description of Microsoft Incident Response recommendation read the article below:
Responding to IT Security Incidents