Threat Level: green Handler on Duty: Johannes Ullrich

SANS ISC: ACK-SYNs from ICS IPs - Internet Security | DShield SANS ISC InfoSec Forums


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
ACK-SYNs from ICS IPs
Hi,
since the beginning of December I'm seeing a lot of blocked ACK-SYNs on my Sophos UTM firewall every day, which come all from IPs from this list: https://isc.sans.edu/feeds/topips.txt
As far as I can see I have no system which is try to establish a connection to one of this IP addresses.

The source port is always TCP/80 and the destination port is always TCP/28987. Mostly the "attack" begins around 04:00a.m. CET and ends around 05:00p.m CET, but sometimes it's going on the whole day.
Here's an example from my log:

2016:12:19-04:08:53 jasnet ulogd[19766]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth0" srcmac="xx:xx:xx:xx:xx:xx" dstmac="yy:yy:yy:yy:yy:yy" srcip="158.69.226.192" dstip="SOPHOS_UTM" proto="6" length="44" tos="0x00" prec="0x00" ttl="51" srcport="80" dstport="28987" tcpflags="ACK SYN"

I guess it's nothing bad, but I would like to understand what's going on.

Thank you,
Jas
JasMan

2 Posts
It looks like someone is spoofing your address to make these connections. This is a common technique to either DDoS these targets, or DDoS you with the reply traffic. Some devices will flood a network with SYN-ACKs if you don't reply with a Reset (try to configure your firewall to not just drop the packets, but to send a reset back. this may reduce the attack volume) Johannes

2799 Posts
ISC Handler
Thank you for your fast reply.

I will try to force an IP change. Hope it will help.
JasMan

2 Posts
Did you consider setting syn-cookies if available on this device ? JL

1 Posts
As I work in Co-Sharing Work place. T do blogging and writing. But when i try to reach more sites of blog or articles, some show we don't allow 2 account on same IP and some times they show your IP is blacklisted. I mailed them but they didn't respond. Any solution for this. Maybe other colleagues in this working place done something terrible on these sites. but is there anyway by that i can Get one new unique ip by that i can access those sites. thenortonsetup

1 Posts
I wrote a long and detailed reply yesterday and again today, but neither make it through. Attempt #3...

It is similar to Mirai. We have been seeing that pattern of SynAcks also since 18th/September - first seen from CloudFlare (CF):

Timestamp (UTC) Action I/F SrcIP [:Port] -> DstIP[:Port] Proto [Flags]
==============================================================================================
2016-09-18 07:56:59 block in on wan from 162.159.209.20:80 -> MyIP:32840 tcp flags:SA
2016-09-18 08:03:42 block in on wan from 162.159.209.20:80 -> MyIP:32840 tcp flags:SA
2016-09-18 08:14:57 block in on wan from 162.159.209.20:80 -> MyIP:32840 tcp flags:SA
==============================================================================================
Found: 3 Displayed: 3
First seen: 2016-09-18 07:56:59 Active: 0:17:58
Last seen : 2016-09-18 08:14:57 ( 121 days, 14:22:46 ago )

Notes:
1) We made *no* outbound connections to that CF IP at that time.
2) The destination port on our side (32840) was extremely common for exactly this pattern of SynAck behaviour (Found 3,848 messages)
3) Obviously they are reflected SA's from someone else spoofing our IP - given point (1) above and the very unlikely proposition that CF would be performing this type of behaviour intentionally.

Volume started very low:
35 from 18-31st September (23 of which arrived on 2 separate days on 21st and 23rd),
29 in October (25 on the last day of the month) and then it ramped up significantly to...
1194 in November and
2590 in December.

Then it stopped using port 32840 and switched to random ports (maybe they saw your post;) - but the ack# remains static.

Up until 1 Nov this is the breakdown:

Value % Count
132.148.4.223 39.06% 25 <- GoDady hosted site
111.13.101.208 7.81% 5
103.3.175.140 4.69% 3
162.159.209.20 4.69% 3 <- First seen from here.
167.114.34.231 4.69% 3
192.99.39.113 4.69% 3
52.77.94.172 4.69% 3
52.69.86.161 3.13% 2
178.32.47.36 3.13% 2
51.255.211.193 3.13% 2
198.50.160.240 1.56% 1
62.210.56.154 1.56% 1
182.106.195.2 1.56% 1
91.134.231.76 1.56% 1
52.76.186.105 1.56% 1
212.22.93.32 1.56% 1
149.56.180.255 1.56% 1
149.56.154.194 1.56% 1
149.56.149.42 1.56% 1
54.169.184.178 1.56% 1
54.251.163.169 1.56% 1
104.31.84.205 1.56% 1
52.76.243.119 1.56% 1

We labelled it MiraiV2, because if you examine the acknowledgement number you may notice a very interesting pattern.

The Ack# can be calculated directly from _our_ IP address with this formula:
SynAck Ack# = ( (o1 - 1) << 24) + (o2 << 16) + (o3 << 8) + o4

Note: o1.o2.o3.o4 is our IP address, not the source IP.

We would expect a MiraiV1 SynAck response from a spoofed packet to have Ack# = Mirai + 1, not (o1 -1)...

[Mirai version 1 is simply seq # (o1 << 24) + (o2 << 16) + (o3 << 8) + o4, as detailed at line 225 in mirai/bot/scanner.c in github's copy]

Hence we believe this traffic serves 2 purposes:
1) (D)DoS the web server at target1 (CF in this case) using our spoofed IP address with the intention of also...
2) ...(D)DoS'ing the real IP owner (us) with SA traffic. Why else would the Ack be pre-calculated from your IP address?

Perhaps a 3rd purpose is to distract both parties (CF and us) so as to hide their real intent/location for a longer period.

If you calculate the ack from your IP, you can create a suricata/snort rule for it thus:

alert tcp any any -> any any (ack=( (o1 - 1) << 24) + (o2 << 16) + (o3 << 8) + o4; msg:"MiraiV2 scan";....)

Contrast that with the MiraiV1 rule:
alert tcp any any -> any any (seq=( o1 << 24) + (o2 << 16) + (o3 << 8) + o4; msg:"MiraiV1 scan";....)

FYI we have noted the following other variants, each using slightly modified sequence or acknowledgement numbers calculated directly from our IP:

Version Calculated Seq/Ack #
v1 (o1 << 24) + (o2 << 16) + (o3 << 8) + o4
v2 ( (o1 - 1) << 24) + (o2 << 16) + (o3 << 8) + o4
v3 ( (o1 - 1) << 24) + (o2 << 16) + ((o3 - 64) << 8) + o4
v4 ( (o1 - 12) << 24) + (o2 << 16) + (o3 << 8) + o4
v5 (o4 << 24) + (o2 << 16) + (o3 << 8) + o4

(I doubt my alignment will carry through - apologies for non-alignment but outside my control)

Most recently we have witnessed a more adventurous manipulation:
v6 ( bitflip( (v1 >> 16 ) + 1 ) << 16

We have seen many more where the lowest 16 bits were all 0, a very unlikely scenario for most TCP stacks, and clearly a calculated value.

We live in interesting times.

HTH
AndrewJ

2 Posts

Sign Up for Free or Log In to start participating in the conversation!