Incorrect results for possibly downed hosts

[vermsec]

Hi @d0nutptr! Thanks for the tool its really the best.

I've noticed one issue with it when using it in my workflow. So what I do is after getting the subdomains from various sources I do a DNS resolve on them to get the IP addresses and use armada to check all TCP 65535 ports. Here if any Host is down or doesn't exist anymore armada responds weirdly on it. Its either all 65535 ports which are open or a lot of ports majorly sequential in order which it says are open. When in reality none of the ports are open. I've verified this issue with multiple such hosts and also tried different levels of rate limiting but still the behavior persists. And I've verified the host with nmap which responds the host is down and if I use -Pn it says all ports are filtered. But armada sees these filtered ports as open.

For instance I ran against this IP 103.97.3.19:

Now if I run armada on the same host:

And the final result which armada gives is majorly all the ports are open (Even with ratelimiting the results are pretty much the same):

Which if we verify with nmap, we get them as filtered

I'm not sure if this is intended to keep high speed for scans but if we can add a ping sweep or a way for armada to better detect this would be really good. My current workaround for this is to do a ping sweep via nmap and then use all the live hosts for armada to scan on. I guess results like these must be similar on hosts behind a firewall.

[d0nutptr]

Oh that's really interesting!

Thanks for sharing so much detail - this really is the ideal Github issue xD

Sometime this week I'll go and dig into the issue and write a fix! Armada's interpretation of packets is a little basic, tbh. It looks for certain flags in a response and doesn't do much else. I will go back and build a more accurate host detection based on what nmap is doing :)

[vermsec]

Hi @d0nutptr, Any update on this?

[d0nutptr]

Oh shit.. so sorry on that. I'm opening the project up right now and will begin debugging :)

[d0nutptr]

Okay, so the update:

I've been able to reproduce the issue locally, though it's inconsistent. I see some discrepancies from how nmap and armada are sending packets (they're close, but different).

I have two theories on what could be causing the problem but I think i need to wait until tomorrow since the subject IP stopped doing the behavior after enough testing 😅

The two ideas are:

• Nmap juggles sending ports, armada does not. I can force nmap to use a specific port instead of juggling them which could help me see if nmap can cause this non-filtered behavior; however, by the time I thought to try this the IP stopped exhibiting the behavior 😞

• TCP End of Option List marker. Nmap does not send this, armada does. This is causing armada packets to be 8 bytes longer than nmap's packets. Based on the way I'm sending the packets, I'm not sure how to control this so it'd be a bit more of a time investment to figure that out. If the port juggling doesn't seem to be the cause, i'll investigate this one.

Anyway, I'll try and pick this back up tomorrow but I may have to wait until Thursday night as my Wednesday is a little busy!

[vermsec]

No worries! Thanks for the update😊

You're right about the inconsistency of this issue, I've seen this happening on other IPs as well but works sometimes.

[d0nutptr]

Awesome update!!!!

I've been able to get nmap to recreate the issue by restricting transmission to a particular ephemeral port.

This indicates that, to resolve the issue with armada, we need to rotate the transmission of packets with a couple of ephemeral ports.

I'm actually considering rewriting armada with some significant improvements in other areas, but this makes sense to include for reliability.

[d0nutptr]

Hmm actually I'm less sure now ^^;

Nmap actually reports all of those ports open even if you let it juggle the ports. It appears to be a speed issue.

Nmap is correctly reporting them as filtered when the scan is slow, but if i set the minimum rate to 1000 then nmap starts reporting all of them as open just like armada.

Armada has a default speed of 10k packets a second. If you reduce that down to 50 then armada begins correctly reporting the ports as not open.

So, in conclusion, you probably need to run armada with a slower speed. For example:

# to run armada at 50 packets a second
armada -t <IP> -p <PORTS> --rate-limit 50

Let me know if this helps and is sufficient for your issue!

[vermsec]

I'm not sure if speed is the issue here, I've tried --rate-limit with 10 and 50 values but still I get random ports reported as open.

While on some IPs Armada's speed is no problem and reports accurate data. Can we add another verification step right after the port scan where armada sends packets again to the discovered open ports to verify if they indeed are open. It won't take a huge hit on the speed I think but an additional --verify option to check would be good.

[thiezn]

I've been working on my own SYN port scanner and indeed see similar behaviour with certain ip ranges (e.g. 194.53.208.0/22). When scanning on high(ish) speeds they start to send SYN-ACK replies on ports that are actually not listening.

In this particular range was already seeing this behaviour on 100 packets per second. My scanner is randomising the source ports and target ip addresses within the range.

I'm pretty sure this is some kind of protection mechanism that kicks in to throw off scanners.

Here's an interesting article of someone seeing similar behaviour on nmap.

Some techniques I'm looking into myself to try and avoid detection:

• Spread scan over multiple source ips (either by splitting the scan over multiple public facing hosts, or attaching multiple public ips to a single host). This would likely be the most effective but obviously less practical. Cloud providers can make this easier.
• Spoof a set of mac addresses and rotate them into the outgoing connections
• Vary TCP options
• Vary TCP window size
• Vary IP TTL