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.
<myip> is a w2k workstation within an ip range protected by a netfilter
firewall. NEW sesisons aren't permitted from the internet to the internal
net.
Until yesterday I received packets only from 126.123.252.5, with a period
varying from 5 minutes to 10 hours, but the average rate is growing. All
the packets are directed to <myip> and none to other ip's in the same ip
range, so the traffic is specifically aimed to <myip>.
So this is not an unusual misconfigured network appliance trying to talk
with the wrong ip address, which was my first thought.
68.76.86.82 is a known blacklisted open proxy, running an obfuscated
tcp/ip stack, but the packet above doesn't come from the proxy daemon
but it's originated by some tool runned on the host. Also 207.75.1.254
has an obfuscated tcp/ip stack (both have a mangled TTL).
126.123.252.5 is, obviously, a iana-reserved non-routable ip address. Why
this kind of address? Maybe because it's the private address of a r00ted
server behind a stateful DNAT firewall or load balancer with no SNAT rules
for the NEW traffic originated from the server. So, the attacker gained a
shell from the outside (the DNAT permit this) but when he try to connect
from there to the outside the traffic is sourced from the wrong ip address
because of the lack of SNAT in this direction.
Actually I'm working on three directions:
1) a trojan/backdor installed on <myip> which sent his haddress (<myip>)
to someone (and now someone is trying to connect);
2) a miscoded trojan/backdor (with <myip> ip address hardcoded for a typing
error) that is trying to call home to notify his address. The coder
erroneusly typed <myip> instead of the real home ip, and so the infected
hosts are trying to contact me instead of the real malware owner;
3) a joke by some good guys.
<myip> is a w2k workstation within an ip range protected by a netfilter
firewall. NEW sessions aren't permitted from the internet to the internal
net. The host is also protected by a personal firewall with application
based egress filtering, two antivirus (one real-time) updated every 6
hours. The workstation is very hardened, with tight acls on code execution
permissions (users and folders) and folder/file access, usually operated
by skilled and security conscious users. For all this I think that point
one isn't a good choice. Since I log session state for all tcp traffic
flowing through the firewall, I parsed the past month logs searching for
unusual tcp sessions originated from <myip>, but nothing strange happened.
I can't say nothing about udp and icmp.
Point 2 and 3 was two good choices until I saw your post.
No other bright idea's, now. Since it seems that also routeable address
(unlike the first one) are involved, I arranged a simple honeypot, but
until now only 126.123.252.5 still try to connect.
> 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:
May 21 03:00:25 fw kernel: CATCHALL IN=eth2 OUT=eth0 SRC=126.123.252.5
DST=<myip> LEN=52 TOS=0x18 PREC=0x20 TTL=105 ID=58793 PROTO=TCP SPT=
38039 DPT=41240 SEQ=2550999126 ACK=0 WINDOW=55808 RES=0x00 SYN URGP=0
OPT (020405B40103030201010402)
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.
<myip> is a w2k workstation within an ip range protected by a netfilter
firewall. NEW sesisons aren't permitted from the internet to the internal
net.
Until yesterday I received packets only from 126.123.252.5, with a period
varying from 5 minutes to 10 hours, but the average rate is growing. All
the packets are directed to <myip> and none to other ip's in the same ip
range, so the traffic is specifically aimed to <myip>.
On Jun 2 I found those two lines:
Jun 2 08:25:59 fw kernel: CATCHALL IN=eth2 OUT=eth0 SRC=68.76.86.82
DST=<mioip> LEN=52 TOS=0x18 PREC=0x20 TTL=109 ID=58793 PROTO=TCP SPT=
38039 DPT=41240 SEQ=2550999126 ACK=0 WINDOW=55808 RES=0x00 SYN URGP=0
OPT (020405AC0103030201010402)
Jun 2 15:34:58 fw kernel: CATCHALL IN=eth2 OUT=eth0 SRC=207.75.1.254
DST=<mioip> LEN=52 TOS=0x18 PREC=0x20 TTL=104 ID=58793 PROTO=TCP SPT=
23657 DPT=41240 SEQ=4057633743 ACK=0 WINDOW=55808 RES=0x00 SYN URGP=0
OPT (020405640103030201010402)
So this is not an unusual misconfigured network appliance trying to talk
with the wrong ip address, which was my first thought.
68.76.86.82 is a known blacklisted open proxy, running an obfuscated
tcp/ip stack, but the packet above doesn't come from the proxy daemon
but it's originated by some tool runned on the host. Also 207.75.1.254
has an obfuscated tcp/ip stack (both have a mangled TTL).
126.123.252.5 is, obviously, a iana-reserved non-routable ip address. Why
this kind of address? Maybe because it's the private address of a r00ted
server behind a stateful DNAT firewall or load balancer with no SNAT rules
for the NEW traffic originated from the server. So, the attacker gained a
shell from the outside (the DNAT permit this) but when he try to connect
from there to the outside the traffic is sourced from the wrong ip address
because of the lack of SNAT in this direction.
Actually I'm working on three directions:
1) a trojan/backdor installed on <myip> which sent his haddress (<myip>)
to someone (and now someone is trying to connect);
2) a miscoded trojan/backdor (with <myip> ip address hardcoded for a typing
error) that is trying to call home to notify his address. The coder
erroneusly typed <myip> instead of the real home ip, and so the infected
hosts are trying to contact me instead of the real malware owner;
3) a joke by some good guys.
<myip> is a w2k workstation within an ip range protected by a netfilter
firewall. NEW sessions aren't permitted from the internet to the internal
net. The host is also protected by a personal firewall with application
based egress filtering, two antivirus (one real-time) updated every 6
hours. The workstation is very hardened, with tight acls on code execution
permissions (users and folders) and folder/file access, usually operated
by skilled and security conscious users. For all this I think that point
one isn't a good choice. Since I log session state for all tcp traffic
flowing through the firewall, I parsed the past month logs searching for
unusual tcp sessions originated from <myip>, but nothing strange happened.
I can't say nothing about udp and icmp.
Point 2 and 3 was two good choices until I saw your post.
No other bright idea's, now. Since it seems that also routeable address
(unlike the first one) are involved, I arranged a simple honeypot, but
until now only 126.123.252.5 still try to connect.
Fabio
PS: sorry for my poor english.
------------------------------------------------------------------------
----
------------------------------------------------------------------------
----
[ reply ]