AdiIRC

Do you run any scripts that uses $urlget or sockets?

Also do you have inline images enabled and/or get favicons from servers?

Per Amundsen wrote in #note-2:

Do you run any scripts that uses $urlget or sockets?

Yes I do have some remotes that will do various lookups. However, they ALL just send requests to my webhost via https. There is nothing that would make requests to random IPs and high ports. I also forgot to mention that I've been wiresharking all port 53 (DNS) requests to try to correlate the IPs to a domain name, but there seems to be no DNS query for any of them. It's just outgoing requests to IP's out of nowhere.

No I do not have inline images or favicons enabled. I didn't even know that was a feature.

Here is a list of all types of network connections adiirc can make:

Connections to a irc server - Any remote server
Check for updates - adiirc.com only
Install updates/mediaplayer plugins/spelling plugin/download dictionaries - adiirc.com only
Get favicons from servers - Some hardcoded domains for networks with a different domain name, others from the serverhost
/google - duckduckgo.com or google.com only
$urlget - Any remote server
/sockopen - Any remote server
DCC - Any remote client/server
Inline Images - Any remote server
/download - Similar to $urlget, any remote server

All my scripts use a common pattern:

 sockopen -e webhostsock mywebdomain.com 443

Then there's

opensock {
  sockwrite -tn $$1 $eval(GET,0) https://mywebdomain.com/path/to/scripts/ $+ %getreq $eval(HTTP/1.0,0)
  sockwrite -tn $$1 Host: $sock($$1).addr
  sockwrite -tn $$1 $eval(Content-type: application/x-www-form-urlencoded,0)
  sockwrite -tn $$1
  unset %getreq
}

This code is probably terrible. It's really old mircscript long before the modern url features. But it works, so I don't bother to retool. Anyway I can't see how this code would trigger these random outgoing IP requests.

The only other thing I can think of is if someone is trying to CTCP me with time or version, I have some overrides for those:

CTCP *:TIME:*:ctcpreply $nick TIME %ctcptime | halt
CTCP *:VERSION:*:ctcpreply $nick %ver | halt

Where I set responses in those vars. But I would expect to see the CTCP incoming requests either in my servers status window or the active channel, and I do not.

Not sure what these $eval's are for. Two things I would try for no particular reason other than debugging, /echo the output from $sock($$1).addr to see what it thinks the ip address of that domain is, and also try disabling the script and see if anything changes.

The ip addresses all seems to point to some type of internet provider, that does make me curious.

Yes that's my web host. Those are my scripts that respond to various in channel commands -- a fairly common case in irc chat. I guarantee there is nothing wrong with this socket set up other than it's ugly, old, and probably using unnecessary calls like those evals(). I lifted it from somewhere probably 20 years ago. But it works 100% of the time. What I don't get is 1-3x a day I get these weird outbound requests to IP's where no DNS lookup was performed and it's almost always to some random ISP allocation, meaning not servers but other residential IP's. If this were a torrent client, I'd think nothing of it. But for an irc client, it's extremely strange.

I don't think there is anything wrong with the script, but since it's the only thing there is to test right now, it would be great to rule out some kind of bug in adiirc socket implementation.

It's pretty unlikely a bug would connect to random internet provider ip address though, but I'm not sure what else it could be at the top of my head.

One other far fetch possibility is there is something inside the .NET framework performing some kind of lookup, maybe checking if the internet connection is working or something like that. Some quick googling has not reveled anything so far.

Oh yeah the .NET libs -- that had occurred to me. But I really only ever make requests to my web server. I then run "plugin" scripts that do all the heavy lifting -- they're the ones that talk to the internet at large (random URLs, youtube, twitter, etc.). Also I could see the .NET libs trying to consult some OSCP site or query for Certficate CRL's or something along those lines. But then there'd be a corresponding DNS query made, which isn't happening.

Unless I have somehow gotten an infected copy of the .NET libs when I updated them with WingetUI (an updater tool). But that tool is pretty well known and open source. Hmm. Remind me again which .NET lib version does adiirc use?

There are builds for -Net 2.0, 4.5 and 4.8, but 4.5 is the preferred one and the one used in the installer.

Since you are connecting to your webserver through HTTPS, you might be on to something about .NET performing some kind of certificate validation.

If the IP's weren't so suspicious, I could believe that. Like the seedboxes one has a working http daemon:
https://185.149.91.161/

which servers a wildcard cert for *.seedboxes.cc
https://seedboxes.cc/

This is just a vps host for torrenters (and possibly malicious actors).

https://169.150.223.202/ serves up a wildcard cert for *.lw903.usbx.me
https://lw903.usbx.me/ and the IP both point to the same status page...

https://162.231.203.192/ has a self-signed cert and takes me to a sonicwall login screen

Could be the hosting company for the seedboxes, but yes that does makes it less likely to be some kind of lookup.

Very puzzling.

Alright I don't think we're gonna figure it out. I wish more people used outgoing restrictions on their firewalls to track stuff like this. It would be helpful to know if this is peculiar to me or others are experiencing similar. Right now, I feel like it's peculiar to me but it may not be. Anyway, thanks for your prompt responses and attempts to help. Adiirc is a wonderful product, and I'm very glad to be out from under the thumb of mirc. Your program is superior.

Oh just got another one a minute ago:
2023-12-02 01:07 37.48.95.184 63263 LEASEWEB-NL-MNT

This serves up an nginx default screen and wildcard cert of *.joker.seedhost.eu

I'm glad you found AdiIRC useful.

I haven't heard about others mentioning something similar, but I will ask around. I'll let you know if I discover something or I can think of something else to check.

If those connections are tied to Adiirc, can you pinpoint what you're doing in adiirc to trigger the connections?

What is the name of this firewall, wonder if it's possible that it's misreporting where the network request originated from.

Do you see any similar network request from other programs when adiirc is not running? Maybe from some other .NET program.

Comodo Internet Security Suite is the firewall. What's odd is that I've used it for years and never had a problem like this before.

So check it out. I exited my torrent client and didn't have one errant outgoing request from adiirc all day. At this point, I'm placing the blame squarely on CIS for some bug that they will likely never be able to recreate or fix. At this point, I'll focus attention on CIS -- restart it, possibly reinstall it.

Thanks for taking the trouble and wasting time on it. I felt you were owed a decent explanation.

Feel free to close or delete this issue.