Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

We had an issue recently on a network where spam email was being sent. The server itself showed very little outgoing traffic, just a lot of incoming postmaster delivery failed messages. The logs showed little to nothing and even doing a capture of packets on the server wound up showing little to no useful information for me to sift through.

The company wound up blacklisted, we randomly checked all the computers and were lucky enough to hit the computer with the infection pretty quickly. One of the computers on the network had a root-kit and it was presumably sending out emails as a fake email server. That's what I took from the situation anyway.

I consider myself to be pretty damn good with networking, and I see no reason why a virus could not simply send an email to another server from a workstation in a network, pretending to be the local domain and be SUCCESSFUL at penetrating spam filters. Assuming the exchange server is running under the same ip address (and at this location it was)

So, this is a two part question, 1. Is there some part of the email system im missing that makes this impossible, and I'm barking up the wrong tree? 2. If I am right, and it was a 'Fake Email Server' sending out those emails, would there be any problems that arise from me blocking all traffic through the firewall that has a DESTINATION port for email traffic that doesn't originate from the server?

I'm pretty new to being a network admin, so I could be a few ball parks over, but this is something that's been bugging me for about a week now. Hell, for all I know this is how all spam viruses work (I had assumed they generally went through the main exchange server)

Any advice on this topic would be appreciated, a quick search online didnt really turn up a lot for information about "Rogue smtp servers" except on a site that requires you to have a membership to view answers (we all know that site)

share|improve this question
    
I had a similar case once. I placed a rule on the firewall to log all traffic targeting port 25 that didn't originate from our mail server. That way I could instantly track down the infected client. Nobody is supposed to talk directly to any server on port 25, except it's our mail server. Additionally, other servers should reject emails from IP addresses that aren't registered as MX. But that is rarely implemented, from what I can tell. –  Oliver Salzburg Apr 15 '13 at 16:59
    
Ok, I wasnt really sure if blocking 25 would cause issues or not. Thank you :) –  RyanTimmons91 Apr 15 '13 at 17:00
    
Personally, I would consider it a valid counter-measure against this specific problem. However, if you can, don't forget to log the packets anyway. That way you can detect if a machine is showing the same problem again. –  Oliver Salzburg Apr 15 '13 at 17:03
    
I didn't really want to block / log packets until I was sure that that was the only thing that should have a destination of 25, and no, ofc its not going to solve the entire problem, but its certainly a step in the right direction. –  RyanTimmons91 Apr 16 '13 at 0:19

1 Answer 1

Just FYI, malicious programs can and do modify the source / destination port / ip of packets. They won't necessarily be able to trick smart SPI on routers (unless the routers are infected), but they can sometimes evade simple firewall rules by changing IP headers or TCP headers in the case of ports.

As to your question -- malware authors would consider a server of any sort (especially a mail server) to be a more valuable prize than a simple workstation. This is because servers are inherently given greater trust in the network than a client endpoint. Infecting only a mail server software by itself is not all that useful, but you can also tweak the firewall settings and send copies of all the organization's email traffic (inbound and outbound) by infecting a server.

If their goal is just to send emails, then sure, the easiest way is to piggy back on the user's existing mail sending routines, and the mail server will be none the wiser unless it spots spam-ish words in the outgoing email and snags it.

If they want to not only send emails but be privy to private communications within the organization, then they'd infect a mail server.

The reason they might have done up their own embedded SMTP server (on a workstation, I'm assuming) is that you're not then beholden to the outgoing mail spam filters of the downstream SMTP server. As a malware author you don't want to rely on bypassing legitimacy checks, you want to route around them entirely. Of course, many routers are configured to block mail protocols such as Exchange and SMTP on all routes except to the certified mail server, to prevent exactly this type of exploit.

(Updated below)...

  1. Is there some part of the email system im missing that makes this impossible, and I'm barking up the wrong tree?

Sending mail "as" the authorized user using the user's own account credentials isn't impossible, but for certain clients it can be quite difficult to do it undetected if the client is resistant to automation such as Outlook. You also then need to write software for each particular mail client and try to anticipate and evade potential issues that might trigger pop-up dialogs letting the user know of a potential problem, etc.

I don't think you're barking up the wrong tree, but implementing a micro-smtp server in your malware is going to be more likely to succeed, unless there are routing rules set up to block it (which there aren't in many networks, including yours apparently).

  1. If I am right, and it was a 'Fake Email Server' sending out those emails, would there be any problems that arise from me blocking all traffic through the firewall that has a DESTINATION port for email traffic that doesn't originate from the server?

This won't be a problem, but it won't make you secure, either.

To be totally secure, you need to null route all traffic on all endpoints by default, and force all clients to use an HTTP proxy that inspects all the traffic and "understands" HTTP (as well as either a well-maintained blacklist, or whitelist of allowed sites).

The reason why simply writing a routing rule for the SMTP port won't work is that they might just use other ports for malicious activity.

The problem we're seeing now (we = security community) is that the new wave of attacks don't use any exotic ports or protocols at all, it's all based on HTTP and done through the browser now. Something as harmless as visiting msn.com can lead to stored XSS, resulting in malicious javascript running in the browser that sends email via webmail, steals information, or uses local computing resources for the attacker's gain (botnets, DDoS, bitcoin mining, etc). We've created a monster. The web is pretty much a not-really-mitigated, gaping security hole all by itself, even once you block execution of foreign executables and lock down your network behind a smart proxy.

share|improve this answer
    
that's what i was wondering, if it were possible. The mail server itself is not compromised, and as far as I can tell neither was the users password. (Changed it anyway ofc) As far as the port changing goes, if sending to a remote server to send email, it would have to have a specific destination port, yes? They wouldn't be able to get away with changing the destination port then because it would never reach the correct port on the destination server. Its a SonicWall, pretty good firewall, I just don't think the server restriction you talked about is in place. yet. –  RyanTimmons91 Apr 15 '13 at 16:34
    
Well they could relay it through a server on an alternate port, but then they'd have to specifically know about (or operate themselves) an SMTP server on a non-standard port. Some legitimate ones may exist, but if the attacker has to host the relay, they'd probably do it on someone else's computer (a botnet), not their own paid for dedicated server infrastructure, as it'd get shutdown in a heartbeat. –  allquixotic Apr 15 '13 at 17:06
    
Come to think of it, that's pretty ingenious: the malware could both try to send mail on an SMTP server, and set up a listening SMTP relay on a weird port, and use NAT-T or outbound-first or other protocol tricks to relay SMTP to a non-standard port. –  allquixotic Apr 15 '13 at 17:08
    
but if you bounce through a relay its not going to have the correct return ip, so it should come up as spam anyway, yes? –  RyanTimmons91 Apr 16 '13 at 0:20

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.