We received two reports of fake UPS invoice tracking Trojan zip files.
This is similar to other invoice Trojans we have seen.

Here is one of the email bodies notice that while this appears to be a two way conversation it was really just the spammer who created the whole thing. The victim did not send UPS an email.Email header:

A coworker (Matt) and I wanted a shorter name for ssh brute force password guessing and we combined ssh shell and phishing into SShellPhishing.

We continue to see ssh brute force password guessing attempts. Occasionally we see large increases. We have seen the attacks switch from one host attempting lots of passwords to lots of hosts that appear to share a dictionary attempting a few password username combinations (coordinated and distributed).
That was the direct result of limiting the number of times an ip could attempt to login
(fail2ban, bruteforceblocker, denyhosts, sshdfilter, pam_abi, ...).
So the cyberwar arm’s race continues with the bad guys developing tools and methods to get around common mitigation methods.

I recently wanted to validate some SShellPhishing reports I received.
One of the validation steps I used was to check those reported ip addresses against this SShellPhishing blacklist run by Daniel Gerzo. It has nearly 3k entries.
http://danger.rulez.sk/index.php/bruteforceblocker/
I spot checked about 40 IP addresses with other SShellPhishing lists also but every ip I checked also appears on Daniel’s list. So while I didn’t get a chance to validate his work in my previous diary https://isc.sans.org/diary.html?storyid=3529
I am now willing to say that I believe Daniel’s list has a very low false positive rate. I saw no false positives so the percentage has to be near 0%. If anyone else has the time and wishes to validate portions of his list I would appreciate any feedback.

This diary had a fairly large list ssh brute force password guessing mitigations and tools.
http://isc.sans.org/diary.html?storyid=846
Combining some of those mitigation recommendations for a defense in depth approach is a good idea.
I recommend moving your ssh from port 22 as we have yet to see a single report of SShellPhishing against a port other then 22. For those of you that think that is simply security via obscurity I would agree with the following caveat forcing the bad guys to scan all 64k ports on a system prior to attacking to find the ssh port adds to the time it takes to compromise systems. It buys system owners time to react potentially preventing compromise. It buys ISPs time to notify compromised customers and it is fairly noisy.