An interesting malware attack showed up in two of my honeypots one morning this week. I then received a third copy from a co-worker later that morning, so I did a little research to gather enough data for a blog post.
The e-mails are interesting, since they purport to be simple bills or invoices (“pending payment requests”) owed to one business, but often claim to come from a separate organization like the US Treasury. (Why the Treasury would want to be involved with making sure I paid a bill from Pizza Hut is an interesting question… But who am I to question the methods of the Bad Guys, since they make a lot more money than I do?)
The second example, sent to a different honeypot account, looked like this:
The third example was the one I got from a Blue Coat employee. Like the first example, it purported to be from someone at “treasury.gov” (although it used “admin” instead of “manager” as the sender):
We recorded a payment request from "Deere & Company" to enable the charge of $125.74 on your account.
Receipt number: 49672385
The payment is pending for the moment.
If you made this transaction or if you just authorize this payment, please ignore or remove this email message.
The transaction will be shown on your monthly statement as "Deere & Company".
If you didn't make this payment and would like to decline it, please click on the link below:
decline transaction #48787027 from "Deere & Company": $125.74
Best regards,"Deere & Company"
If the recipient of such a spam clicked the “decline” link (which they would, if they believed the spam, since of course the charge from the random company was not one they remembered making), they would be taken to a site with a believeable name, like pending-payment.com or us-credit-security.com as a first-stage relay. That’s when the real action began, as the apparently empty page there actually contained an iFrame linking the victims to onlineshop24s.com.
When I attempted to visit onlineshop24s.com, I was blocked by my trusty ProxySG, which declared it to be a malware site. I checked our database at that point, to see how long we had known about it, since the timestamp on the e-mail was pretty fresh, and I was impressed that we had already caught it. However, onlineshop24s.com wasn’t in the database — meaning that this had been a real-time catch by WebPulse. (Which was even cooler.)
Out of habit, I went ahead and added onlineshop24s.com to the database, but reflected as I did so on the difference a year makes. A year ago, I would have been monitoring the spam honeypots much more rigorously, and when I saw something like this, I would have immediately leaped into action, investigating both the first-level relay domain and the second-level host, spending a lot of time in our logs mapping the attack. This time, seeing that WebPulse already knew about the threat host, I could pretty safely assume that it was part of a Malware Delivery Network that we knew about, and so there was no urgency for me to investigate right then. (And, as it turned out, I was right.)
So how did WebPulse know about the attack domain — even before it showed up? Because it was simply the latest domain appearing on a malicious server. And WebPulse already knew about that server — having spotted the first domain when it initially showed up in our logs several days previously — and automatically linked that server to others already seen in the network.
It’s enough to make a malware researcher get lazy…
–C.L.
Leave a reply
