# Compromised email account leads to unstoppable spam

## hanj

This morning I discovered that an email account was compromised and the server was sending (spewing) spam from this user. The SMTP connections were distributed across a wide range of IPs all over the world. This is a virtual mail system (postfix, amavis, etc) so I thought I would simply lock (active = 0) the user, change the password and we'd be good.

I did this, but to my surprise, I continued to see logins and mails being sent. I changed the username and tested connection via telnet, and I could not authenticate, yet the authentications continued... 

```

May 20 10:42:45 comp postfix/smtpd[25059]: 1CBD452C188: client=unknown[202.168.155.92], sasl_method=PLAIN, sasl_username=jen@domain.com

May 20 10:43:04 comp postfix/smtpd[25334]: 884A252C190: client=unknown[190.13.31.179], sasl_method=PLAIN, sasl_username=jen@domain.com

May 20 10:44:05 comp postfix/smtpd[3353]: A070F52C0E8: client=unknown[177.21.26.9], sasl_method=PLAIN, sasl_username=jen@domain.com

May 20 10:44:21 comp postfix/smtpd[26368]: 374BA52C180: client=unknown[41.225.9.177], sasl_method=PLAIN, sasl_username=jen@domain.com

May 20 10:44:21 comp postfix/smtpd[26966]: CEF8852C18A: client=unknown[84.95.57.198], sasl_method=PLAIN, sasl_username=jen@domain.com

May 20 10:44:41 comp postfix/smtpd[25334]: 48FD052C18B: client=unknown[190.13.31.179], sasl_method=PLAIN, sasl_username=jen@domain.com

May 20 10:44:43 comp postfix/smtpd[25059]: E585652C18F: client=unknown[202.168.155.92], sasl_method=PLAIN, sasl_username=jen@domain.com

May 20 10:45:45 comp postfix/smtpd[3353]: D089352C193: client=unknown[177.21.26.9], sasl_method=PLAIN, sasl_username=jen@domain.com

May 20 10:45:59 comp postfix/smtpd[25334]: B42ED52C19D: client=unknown[190.13.31.179], sasl_method=PLAIN, sasl_username=jen@domain.com
```

I thought it might be cached smtp sessions, etc.. but I restarted all mail related services, the problem continued.

I noticed the sasl_method being PLAIN for these requests, typically this would be using the LOGIN mech. What I did was removed that particular mech from smtpd.conf and restarted saslauthd and I immediately saw connect/disconnect, but not longer sending spam. It almost appeared they were bypassing authentication all together (open relay). I did multiple tests, and all tests came out clean for open relay. I feel like there is a misconfiguration.. something stupid... here is my main.cf

```
local_destination_concurrency_limit = 2

default_destination_concurrency_limit = 20

debug_peer_level = 2

debugger_command =

         PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin

         ddd $daemon_directory/$process_name $process_id & sleep 5

sendmail_path = /usr/sbin/sendmail

newaliases_path = /usr/bin/newaliases

mailq_path = /usr/bin/mailq

setgid_group = postdrop

html_directory = no

manpage_directory = /usr/share/man

sample_directory = /etc/postfix

readme_directory = no

inet_protocols = ipv4

home_mailbox = .maildir/

unknown_address_reject_code = 554

unknown_client_reject_code = 554

unknown_hostname_reject_code = 554

smtpd_discard_ehlo_keywords = silent-discard, dsn

smtpd_helo_required = yes

disable_vrfy_command = yes

smtpd_helo_restrictions =

   permit_mynetworks,

   permit_sasl_authenticated

127.0.0.1:2528_time_limit = 3600s

smtpd_client_restrictions =

   sleep 5

   permit_mynetworks,

   permit_sasl_authenticated,

   check_client_access tcp:127.0.0.1:2528,

   reject_rbl_client zen.spamhaus.org

smtpd_sender_restrictions =

   check_sender_access hash:/etc/postfix/amavis_senderbypass,

   check_sender_access hash:/etc/postfix/sender_access,

   check_sender_access pcre:/etc/postfix/sender_access_pcre,

smtpd_restriction_classes =

        check_policyd_weight

check_policyd_weight =

    check_policy_service inet:127.0.0.1:12525

header_checks = regexp:/etc/postfix/header_checks

smtpd_recipient_restrictions =

   permit_mynetworks,

   permit_sasl_authenticated,

   check_helo_access regexp:/etc/postfix/helo_access

   check_client_access hash:/etc/postfix/client_acl

   reject_invalid_hostname,

   reject_non_fqdn_sender,

   reject_non_fqdn_recipient,

   reject_unknown_sender_domain,

   reject_unknown_recipient_domain,

   reject_unauth_destination,

   reject_unauth_pipelining,

   check_client_access cidr:/etc/postfix/whitelist.cidr,

   reject_unauth_destination,

   check_policy_service inet:127.0.0.1:10030,

   check_client_access tcp:127.0.0.1:2528,

   check_client_access hash:/etc/postfix/rbl_override,

   check_client_access cidr:/etc/postfix/rbl_override.cidr,

   reject_rbl_client cbl.abuseat.org,

   reject_rbl_client bl.spamcop.net,

   reject_rbl_client zen.spamhaus.org,

   reject_rhsbl_sender fresh15.spameatingmonkey.net,

   reject_rhsbl_client fresh15.spameatingmonkey.net,

   reject_rhsbl_sender uribl.spameatingmonkey.net,

   reject_rhsbl_client uribl.spameatingmonkey.net,

   reject_rhsbl_sender urired.spameatingmonkey.net,

   reject_rhsbl_client urired.spameatingmonkey.net,

   reject_rbl_client b.barracudacentral.org,

   reject_rbl_client bl.spameatingmonkey.net,

   reject_rbl_client backscatter.spameatingmonkey.net,

   reject_rbl_client bl.spameatingmonkey.net,

   reject_rbl_client backscatter.spameatingmonkey.net,

   reject_rbl_client bl.spameatingmonkey.net,

   reject_rbl_client spamsources.fabel.dk,

   reject_rbl_client truncate.gbudb.net,

   reject_rbl_client psbl.surriel.com,

   reject_rbl_client cidr.bl.mcafee.com,

   reject_rbl_client spam.spamrats.com,

   check_client_access hash:/etc/postfix/policyd_weight_client_whitelist,

   check_recipient_access hash:/etc/postfix/policyd_weight_recipient_whitelist,

   check_recipient_access hash:/etc/postfix/policyd_weight_users

content_filter = smtp-amavis:[localhost]:10024

message_size_limit = 50000000

smtpd_sasl_auth_enable = yes

smtpd_sasl_security_options = noanonymous

smtpd_sasl_local_domain =

broken_sasl_auth_clients = yes

smtpd_use_tls = yes

smtp_use_tls = yes

smtp_tls_note_starttls_offer = yes

smtpd_tls_key_file = /etc/postfix/certs/newreq.pem

smtpd_tls_cert_file = /etc/postfix/certs/newcert.pem

smtpd_tls_CAfile = /etc/postfix/certs/cacert.pem

smtpd_tls_loglevel = 1

smtpd_tls_received_header = yes

smtpd_tls_session_cache_timeout = 3600s

smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_tls_session_cache

tls_random_source = dev:/dev/urandom

smtpd_relay_restrictions = permit_mynetworks,permit_sasl_authenticated,defer_unauth_destination

virtual_transport = virtual

virtual_mailbox_domains = proxy:mysql:$config_directory/postfixadmin/mysql_virtual_domains_maps.cf

virtual_mailbox_maps = proxy:mysql:$config_directory/postfixadmin/mysql_virtual_mailbox_maps.cf

virtual_alias_maps = proxy:mysql:$config_directory/postfixadmin/mysql_virtual_alias_maps.cf

virtual_mailbox_limit_maps = proxy:mysql:$config_directory/postfixadmin/mysql_virtual_mailbox_limit_maps.cf

proxy_read_maps =

   $virtual_mailbox_domains

   $virtual_mailbox_maps

   $virtual_alias_maps

   $virtual_mailbox_limit_maps

virtual_minimum_uid = 1000

virtual_gid_maps = static:1002

virtual_uid_maps = static:1000

virtual_mailbox_base = /
```

Any ideas?

Thanks!

hanji

----------

## hanj

bump

----------

## Tony0945

As a wild guess, did you restart the service after changing parameters? It would only cost a few seconds of outage to try.

----------

## hanj

 *Tony0945 wrote:*   

> As a wild guess, did you restart the service after changing parameters? It would only cost a few seconds of outage to try.

 

Yep, I totally restarted all services related to SMTP.. postfix, saslauthd, courier-imapd for fun, etc. Every change I restarted all these services. Like I mentioned, once I removed the PLAIN mech, things stopped, but I don't know how/why that would matter.

Thanks!

hanji

----------

## nativemad

Sounds like $config_directory/postfixadmin/mysql_virtual_mailbox_maps.cf  doesn't respect active=0!? Can you post that file?

----------

## hanj

 *nativemad wrote:*   

> Sounds like $config_directory/postfixadmin/mysql_virtual_mailbox_maps.cf  doesn't respect active=0!? Can you post that file?

 

Sure.. here you go:

```
# /etc/postfix/mysql_virtual_mailbox_maps.cf

#

# virtual_mailbox_maps = mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf

user                    = REMOVED

password                = REMOVED

dbname                  = postfix

hosts                  = xxx.xxx.xxx.xxx

table                   = mailbox

select_field            = maildir

where_field             = username

additional_conditions   = AND active='1'

```

Also, this continued to happen after setting active to 0 AND after changing the username/email to a different value. For example I changed username from jen@domain.com  to DUMPjen@domain.com and logins continued to happen. It appears that all the virtual stuff was bypassed??

Thanks!

hanji

----------

## nativemad

hmm... that file looks ok.

Do you possibly have a local unix user with the same name!? Or are you connected to the right DB/table!?

----------

