ircsnapshot icon indicating copy to clipboard operation
ircsnapshot copied to clipboard

Add CTCP scan support

Open ldionmarcil opened this issue 11 years ago • 3 comments

User sae on #r_netsec@freenode suggested adding CTCP scans. I think this would be a great addition in order to get an idea of the different time zones/versions of bots and admins.

I would be ready to implement it but I think a conversation is to be had regarding some topics:

  • On most clients, CTCP queries are the really hard to miss. I'm thinking of mIRC which displays CTCP events in big red bolded text. I'm guessing that in order to preserve the "stealth" factor, it would be best to implement it as an option, and not perform this scan by default;
  • Given the possible size of IRC botnets, would it be best to query a certain ratio of users to be pinged? CTCP querying 100% of users could be time consuming if the network is particularily populated;
  • Another concern about stealth: add the option not to CTCP the ops (possible botnet admins) in order to avoid detection?

Thanks!

ldionmarcil avatar Feb 01 '14 00:02 ldionmarcil

Sounds good, I had put it down in the Todo section of the Readme, but its about time I move features to issues.

Making this toggled is a must, a white list as well is a great idea. I'm not quite onboard for the ratio, at least from the evidence gathering perspective. I think for large networks, the todo for sessions that can be restored after being banned will handle any issues from taking a large amount of time.

Bwall avatar Feb 01 '14 00:02 Bwall

How should we deal with the possibility that clients do not respond to CTCPs?

Example use case:

  • ircsnapshot joins #foobar
  • ircsnapshot sends a CTCP VERSION request to admin1
  • ircsnapshot sends a CTCP TIME request to admin1
  • admin1 sends back a CTCP VERSION response to ircsnapshot
  • admin1 sends back a CTCP TIME response to ircsnapshot
  • ircsnapshot sends a CTCP VERSION request to bot1
  • ircsnapshot sends a CTCP TIME request to bot1
  • bot1 never sends any CTCP replies back because it is simply not implemented in the malware

Should a timeout be implemented for each client, and if no reply is received after N seconds, the task is removed from the processing queue? I believe this is the best option available.

ldionmarcil avatar Feb 01 '14 20:02 ldionmarcil

I agree. A timeout is probably the best method. I'm thinking it could be configurable, but the default should be around a second or two. Any thoughts?

Bwall avatar Feb 01 '14 23:02 Bwall