We’re seeing a huge recurrence of spam thats been getting through our spam filters., all coming from @live.com addresses.
I hadn’t seen any personally until one of our clients brought up the fact that she was receiving 20-30 sex related spam a day, all coming from Random name @live.com addresses.

A check of the logs showed that we’ve received at least 100,000 of these spam mails over the last month that have gotten through to our users.
This is something I’d obviously like to remedy.  Not receiving, processing, or storing that much spam free’s up the servers for other things.

As the number of valid addresses using @live.com accounts appears to be minimal (I could only see a handful of legitimate users sending from that domain), I have taken the decision to block any email from the @live.com domain until Microsoft can resolve their spam issues.

If you do have clients using @live.com addresses, you will be able to send email to them, but not receive from them.
We apologize for the inconvenience, but unfortunately there is no other solution that easily mitigates the issue, other than completely blocking them.

For a more technical explanation of whats happening, read below:
Read more »

One of our clients was sending out spam unknowingly yesterday. I spent most of my afternoon cleaning it up, tracking down how the attackers were doing it.

In this clients case, they have their own server (which we maintain), and they mostly write their own code.
Most of the common garden variety vulnerability scans don’t work on their server, because they write their own code, although in this case it didn’t save them from being exploited.

In order to find out what was causing the spamming, I had to find out how the attackers got in.
Usually this means a check of the apache logs to check for anything untoward.

In this case, although the logs had plenty of vulnerability scans (which were to files that don’t exist on their server), I couldn’t see anything in the logs that immediately stuck out as being the cause.
Read more »

Foreword – Note that none of our servers are vulnerable to remote inclusion attacks.

For the most part, most of the exploits I covered in yesterdays post are common garden php vulnerability scans.
Some of them are more interesting though, although more for being encrypted, than anything else.

If I take an example from our log files:
Read more »