Re: Help with an odd log file...

["James C. Slora Jr." <Jim.Slora () phra com>]

>     Total Length: 52
>     Identification: 0xb82b
>     Time to live: 118
>     Sequence number: 1409168989
>     Header length: 32 bytes
>         .... ..1. = Syn: Set
>     Window size: 55808
>     Options: (12 bytes)
>         Maximum segment size: 1460 bytes
>         NOP
>         Window scale: 2 (multiply by 4)
>         NOP
>         NOP
>         SACK permitted


> From May 21 I received about 120 packets like this one:

> Every packet is identical to each other, except for TTL field, which vary
> from 102 and 108, and IP-ID, always set to 58793 except a couple of times.
> This kind of SYN packet doesn't belong to any known TCP/IP stack. There
are
> a lot of field in common with the packet you have captured, first of all
the
> tcp windows size, but also the tcp options worth a look. Both are
peculiar.
> I think that are crafted by the same tool.

Please forgive my rambling below - I'm all hyped up because I've been
looking at something similar and it looks like something big is happening
under our noses.

I'm getting the same types of packets to a router - since May 17. Also at a
gradually increasing pace - they started about 1 per day and now they are 40
seconds to 40 minutes apart. I attributed them to some lame trojan probe and
did not realize they were related to this thread until I reviewed new
detailed captures when the pace started getting bothersome.

The behavior of mine is identical to yours - TTLs vary 106-112, even on
probes that come a few seconds apart. The overwhelming majority of the
probes come from one address (not the same address as yours and not a known
portscanner or proxy). The very reliable and trustworthy admin of the source
address says the packets did not come from his system, but is continuing to
do full packet capture anyway to make sure.

ID on mine from the primary source is always 0xfb6f. Sequence is always
2773619225. Mine have identical options to yours including WS: 2. The SYNs
do not have data (other than that probably encoded within the TCP/IP
headers). Nothing has followed the SYNs.

These packets are obviously crafted, and the main source addresses (at least
in my case) are probably spoofed. I can't check the true hops to my apparent
main source because it is not a public system and traffic to it is dropped
while still several hops away from it.

Mine are primarily sport 14921 and all dport 8247. I get occasional probes
from variable source ports from addresses different from the primary prober.

I did a factory reset on the router, reloaded firmware, set a new password -
the probes stopped for over 6 hours before starting up again. I don't know
what the * that means.

There are a few other fishy source and dest combinations coming now but they
are still far apart and I don't have full captures to know if they are
related.

My working hypothesis is that the primary probe source is completely spoofed
and is some sort of homing signal for a complex trojan. The oddball probes
are probably not spoofed and are possibly the agents of the actual abusers.
The "agents" have all been dialup or cable modem systems (probably owned),
except the primary prober that is spoofing the address of a very large
semi-government agency.

Now, since multiple sources are involved and the pace is building over
several weeks, I'd say we have some sort of botnet. Since the primary
probing address is spoofed and is appearing to probe at random intervals
with varying TTLs, I'd say multiple systems may be spoofing the primary
address. This may be the botnet membership announcement, and since the TTLs
vary only a little bit the sources may be from the same /16 or so address
range as the target - again typical of botnet probes.

More hypothesis: Each target is assigned a unique combination of source
port, dest port, ID, and Sequence. So this post probably contains all the
info necessary to identify my system.

This is looking a lot like the Q-like traffic that was common late last
year. A Q-based trojan would not need the TCP handshake to complete because
instructions are coded into the SYN (or any other type of packet). The
destination port does not even need to be open.

The interesting thing to me is that nobody has reported to the lists I read
about finding a wild Q-based trojan in files on their system AFAIK, but many
people have logged traffic that looks like it is similar to Q probes. Others
have suggested that there may be a memory-resident Q-like trojan in the wild
that is listening for these packets, but I have not heard of any packet
captures of such a beast.

My paranoid side says that nobody has seen the trojan because it's built
into Windows or WMP or adware or something else with closed source code that
is on lots of systems. Maybe it's designed to help digital rights management
monitoring or something, and is now being abused by unintended parties.

I also can't help but wonder if this traffic might be related to the
stateless Code Red middle packets being logged widely and some Code Red
infections that people are reporting inside hardened systems. A Q-like
trojan could possibly have been triggered by the packets to start sending
Code Red packets even though IIS had been hardened. Maybe someone who has
had this happen could review their logs and compare sequence and IDs on
packets from the source they believe compromised them with a stateless 2nd
packet only of Code Red. If those sequence and IDs correlate with other
anomolous packets, that might establish a link.

CodeRed.F has always seemed to me to have overly robust propagation. AV and
IIS hardening are much more prevalent than when the nearly identical
CodeRed.C was released, but I've logged far more CodeRed.F attacks than I
ever got from C. Maybe it has sometimes been dropped onto systems through
means other than IIS overflows, and is being used to hide more serious
compromises that occurred before the CR infection.

OK, enough wild-eyed rambling for now.



----------------------------------------------------------------------------
----------------------------------------------------------------------------