The past day has been pretty slow, with mainly the usual network noise. Here are some things of interest:

Port 6346 Increase

There has been an increase of traffic on this port, mainly for sources and records. If anyone is seeing this and has any captures, please let us know.

trojan Win32/Small.AR

We would like to thank Chris Norton for his analysis of this trojan and for offering a Snort signature for it. He writes:

"Here we see Small.AR contacting 2 websites 213.46.226.40 [members.chello.nl], 66.150.161.134 [redirectf.dnsix.com]. As to what it was trying to do that remains a mystery as you will find out:

192.168.80.129 213.46.226.40 HTTP GET
/zosman/cia/index.php HTTP/1.1

213.46.226.40 192.168.80.129 HTTP HTTP/1.1 404 Not
Found (text/html)

192.168.80.129 66.150.161.134 HTTP GET /index.php?
HTTP/1.1

66.150.161.134 192.168.80.129 HTTP HTTP/1.1 302 Found

...

the last request was followed by an ACK, FIN/ACK. All that was tried on 66.150.161.134 was a GET /index.php? followed by a 302 and ACK, FIN/ACK.

Here in filemon we can see just what this trojan creates/touches:

[here it creates mssyncr.exe and writes data to it]
7:00:00 PM trojan.exe:720 CREATE C:\WINNT\System32\mssyncr.exe
SUCCESS Options: OverwriteIf Sequential Access: All

7:00:00 PM trojan.exe:720 WRITE C:\WINNT\System32\mssyncr.exe
SUCCESS Offset: 0 Length: 11820

7:00:00 PM trojan.exe:720 WRITE C:\WINNT\System32\mssyncr.exe
SUCCESS Offset: 0 Length: 12288

7:00:00 PM trojan.exe:720 WRITE C:\WINNT\System32\mssyncr.exe
SUCCESS Offset: 0 Length: 12288

other than the usal calls to the dll's needed to run the .exe that is all that was "suspicious"."

He also offers this Snort signature:

alert ip any any -> any any (msg:"Win32/Small.AR outbound activity"; uricontent:"/zosman/cia/index.php"; classtype:trojan-activity; sid:5000824; rev:1;)
SSH Advice for Repeated Hack Attempts

We have received numberous reports on the SSH scanning and brute force attempts. As such, fellow handler Bill Stearns offered some good advice to someone that was receiving continual scans and brute force attempts. I would like to pass along his response and hopefully it will help others. Also, if you've never checked out his website, you really should as there are lots of great resources! It can be found at
http://www.stearns.org

And now for some great advice from Bill:

"You're doing the right thing by reporting the scanner.
Unfortunately, if the ISP can't or won't remove the user's access, you're
left with the nagging question of "OK, the prober hasn't gotten in so far
because they don't have a valid username and password; what happens when
they get one?"
Might I suggest a distressingly simple way to avoid the probes?
Move your ssh servers to a different port. :-) This doesn't stop the
prober, but it gives you one more small roadblock for them; unless they're
specifically targetting you and decide to do a full portscan, they won't
find the ssh server.

If this is a remote box, I'd do this at a time when there are tech
people at your ISP so if something goes wrong you can set things back.
For your Internet accessible ssh servers, change the ssh port used. First, open 3 ssh connections to the box. That gives you some terminals on which to type if ssh doesn't restart or you can't get in for some reason. On Redhat/Fedora Linux, add the port number to the "OPTIONS" line in /etc/sysconfig/sshd :

[root@mysshserver root]# cat /etc/sysconfig/sshd

OPTIONS='-p 1011'

Once you've configured TCP wrappers and/or your firewall to allow incoming connections on the new port (allow traffic on port 22 as well until you're sure this still works), restart sshd:

/etc/init.d/sshd restart

The primary daemon will restart, but your existing ssh connections
on the old port 22 should stay open for emergencies.
On the client, (again, openssh, although nothing I describe here
is particular to openssh, Redhat/Fedora, or even Linux; all ssh clients
and servers can be convinced to use a different port), edit ~/.ssh/config
and add a block like this (substitute the real name of the machine for
"mysshserver"):

Host mysshserver
Port 1011

Now run

ssh mysshserver

and you should be in. Use

ssh -v mysshserver

if you have trouble and need to debug.
Even programs like scp, sftp, and rsync-over-ssh will work just fine with no additional configuration; they all indirectly access ~/.ssh/config and use the port setting. Note that if you ever access this system by a different name (such as "mysshserver.whoevertech.com"), you'll want to add a similar ssh block starting with "Host mysshserver.whoevertech.com").

The above is aptly described as "security through obscurity", and
generally discouraged as the _sole_ protective measure for a system.
Moving ssh to a different port doesn't absolve us from performing all the
other security steps (patching, firewall, locking down ports, services and
users, etc). It does make it harder for the casual prober, though, and
that might be enough to handle the issue if the ISP won't."

1.gif Trojan - Update III

AV providers have provided updated signatures for the 1.gif email Trojan.

TrendMicro - Excellent analysis
http://www.trendmicro.com/vinfo/virusencyclo/default5.asp?VName=CHM_PSYME.N
http://www.trendmicro.com/vinfo/virusencyclo/default5.asp?VName=JS_PSYME.N
http://www.trendmicro.com/vinfo/virusencyclo/default5.asp?VName=TROJ_AGENT.EK

McAfee

http://vil.nai.com/vil/content/v_100715.htm

Panda
http://www.pandasoftware.com/virus_info/encyclopedia/overview.aspx?IdVirus=51466&sind=0

Lorna J. Hutcheson

Handler on Duty

www.iss-md.com