I would really like to know what sort of traffic patterns that caused the detection. How would you accidentally mistake susam.in for a C2 server? Where are they sniffing traffic at to determine this?
This and the "how the fuck does this happen?" comment...
There are two technical components which are salient to the Avalanche story here which are DNS related.
First is <<fast flux>>. A rough sketch of this looks like servers behind reverse proxy servers, and DNS servers. Both the proxy and DNS server components are intended to cycle extremely fast, rendering IP address blocking impractical and tracking difficult. We'd often find that the actual mothership servers used named virtual hosting and by sending different Host: headers we could tickle different phish.
Second is <<DGA>> or a Domain Generation Algorithm, the point of which is to enable autonomous discovery of Command and Control servers by implants. In practice you can think of a DGA as TOTP for domain names. So at any given time the algorithm offers a bag of possible C2 server domain names (which constantly changes) and the implants rattles doorknobs until it hears "notary sojack" from one of them. (There can be lots of these, thousands or tens of thousands at any time.)
I think DGA is the concern here. You may think there's some traffic sniffing going on, but that's only the case for observed implant activity.
Let's look at some implant and its C2 from a traffic standpoint. The implant is going around asking "notary sojack? notary sojack?" to every Tom, Dick and Carol and even to cats and garbage cans. The C2 looks like a garbage can but has an incongruous collection of fans who are also observed muttering "notary sojack" at random objects.
It was possible in most cases to reverse engineer the DGA and seeds with confidence. DNS zones would be populated with the flavor of the day (and maybe the days prior and after) and utilized by caching resolver operators as response policy zones (RPZs) or e.g. Bro lookup tables. The notion being if something in your org (using your resolvers) is doing DNS lookups for a bunch of these, you might want to take a look and see if it's rattling doorknobs and muttering "notary sojack". That's the idea. Technically, somebody could block on it but there is the risk of false positives. Your vendor might vett the list in some fashion; or not.
I don't recall domains being seized as commonplace in my time. I could make up hypotheticals as to what might cause this to occur but I've got no evidence or experience supporting one over another. It could've been a mistake.
In any case, after a few days the DGA moves on and the domain is useless; that comports with the domain being returned to the owner.
Hmm, so then susam.in supposedly came out of a DGA in the wild being observed (or was a reverse engineered possibility) and then matched some level of checks to try to weed out false positives.
Still feels sloppy that their whatever they're hosting looked enough like a C2 server/reverse proxy point to a C2 server to get their domain _seized_. That's quite a drastic action, especially across countries being it's a .in domain.
99% correct in my estimation. Sloppy... that's where I'm not sure; heavy-handed? Certainly. I said I wasn't covered by noncompetes any longer, I didn't say I felt comfortable spilling all on HN. I'm also not current on what covenants are in place around .in specifically.
If I was investigating this I would start with the hosting for susam.in and could it have been compromised.
If threat intelligence intrigues you, you're welcome to stalk me and send me a connection request on LinkedIn. And as a footnote to the "how the fuck..." comment, maybe it should be FCANN rather than ICANN for truth in advertising.
