[Intrusions] SSH scanning, operation of phishing site

dmd at lu-networks.com dmd at lu-networks.com
Thu Mar 23 15:24:20 GMT 2006


Hi Andrew,

Nice report about that intrusion.
My personal choice about these attacks was to change my SSH ports to a
port above 40000,
since then i never even had 1 failed login attempt, exept from myself.
Even if this is security by obscurity i think it's the best method against
autorooters,
limiting the connection attempts and blocking ip's with too many failed
logins are verry effective methods against
indivitual targeted brute force attacks but i think it's way too much if
you only have to deal with autorooters.
Additionally there was a noticable traffic decrease after i changed the
ports.

Some years now i'm doing research on different groups and organisations
involved in botnet's and
automated rooting attacks and i try to fingerprint and classify their
attacks.
Do you still have the files/scripts they left on your servers and some
logs with source IP's ?
If yes i would be glad if you could send them to my e-mail address.

Regards,
Tom de Waha


On Thu, March 23, 2006 2:58 am, Andrew Daviel wrote:
>

> Further to my post of a week or two back, we had another 2 machines hit
> by SSH dictionary attacks (we had locked down root on several critical
> servers, but not everything, and I realized my blocking script was running
> not 4x an hour as I thought, but 4x a day...since fixed in advance of
> getting the realtime script up)
>
> BTW - I have placed an ssh password-guessing list found on a hacked
> machine on http://andrew.triumf.ca/ssh_pass_file - our machine from last
> time had indeed had one of these passwords (qazwsxedc), which explains why
> it was guessed in less than 500 attempts ... not me that chose it, but if
> asked I might have said it wasn't that easy to guess. The scanning script
> also checks a load of user accounts for user=password (e.g.
> candice/candice) plus more guesses for admin, guest, database, postgres
> etc.
>
> I have recently made a hacked version of sshd which logs failed passwords
>  - it might be interesting to see what it finds
> (openssh-4.1p1/auth-passwd.c.mod add after line 116
> if (result == 0 ) logit ("failed password %s", password) ; if interested)
>
> On to phishing .. this was fun ...
>
>
> A machine that had been used as a testbed was still online, with what we
> thought was a reasonably strong password (9 chars semi-random
> alphanumeric). Remote logging had been disabled while testing network
> stuff, so the blocking script was not activated. The password was guessed
> after some 2600 attempts from 58.210.241.210 (CHINANET jiangsu province)
>
>
> The attacker then logged in from (I think) another hacked Linux machine,
> downloaded some phish stuff from an ftp server in Romania (.ro), and
> started up the webserver which had been stopped.
>
> They then created ip aliases (eth0.1, eth0.2 etc.) corresponding, as it
> happened, to addresses assigned to visitors staying in a dormitory up the
> road. These visitor addresses were then advertised in spam email sent
> probably from a botnet (e.g. Bellsouth ADSL), while the "real" address was
> unused. So, when we started getting reports from SpamCop, the finger was
> pointed at the visitor's laptops offsite. It didn't help that one was, by
> coincidence, running Debian Linux.
>
> A report of a machine I knew should be onsite and could not
> possibly host a phishing page clued me in to what was happening, and a
> quick ping and ARP query turned up a MAC address pointing to the real
> culprit.
>
> The attacker had changed the password so I had to boot a CD to get access
>  (pity; could not check running processes, though I did make an attempt
> to dump the warm memory after rebooting). Luckily, the attacker had not
> properly erased the shell history or syslogs so I could read pretty much
> everything that was done.
>
> The phishing script was written in PHP and logged credit card numbers,
> security numbers, user ID and PIN to a text file on the webserver. The
> attacker monitored this file from a browser via a web proxy in Romania
> (cache02.canals.ro). Occasionally they would log in from
> a DSL connction on pacbell.net to check things, and clean the file.
>
> After a few days, while we filtered the aliases as reports came in,
> they installed a second phish package for Chase Manhattan, then attacked a
> second machine, but as it was in use and they broke the network trying to
> install a rootkit, we found it quite quickly
>
> Overall, they got maybe 90 IDs, about 25% of (the undeleted) which were
> bogus or obscene, from about 2000 hits. So that's what, about 3% of people
> who click the email link enter valid data. Who knows how many emails went
> out. We had maybe 40 SpamCop reports to abuse at triumf.ca, several personal
> emails to assorted administrators onsite, and one phone call. Plus (real)
> email from eBay and PayPal (lucky it didn't get filtered, though I think I
> whitelist "abuse@")
>
> The actual phish page started with a regular browser window (exposed URL)
>  saying "our page has moved, click here". The next page was a big window
> with a toolbar but no location box, and all the PayPal graphics etc. No
> SSL, nothing special there, I think. The email was one of the HTML
> messages "we have noticed unauthorized activity on your account. please
> visit the resolution center <a
> href="http://some.triumf.ca/xxx">https://www.paypal.com</a>"
>
>
>
>
> --
> Andrew Daviel, TRIUMF, Canada
> Tel. +1 (604) 222-7376  (Pacific Time)
> security at triumf.ca
>
> _______________________________________________
> Intrusions mailing list
> Intrusions at lists.sans.org
> http://www.dshield.org/mailman/listinfo/intrusions
>
>





More information about the Intrusions mailing list