Live data from Hacker News

A Novel Approach For Computer Worm Control Using Decentralized Data Structures

pdf.yt

11–20 of 50 posts

Re: A Novel Approach For Computer Worm Control Using Decentralized Data Structures

#11
Another similar idea (from back in 2008[1]) is to use the Bittorrent DHT as distributed storage for C&C commands. I have no idea anyone has implemented a real-life bonnet in the intervening six years, but it seems plausible enough.

[1]: https://iseclab.org/papers/securecomm08_overbot.pdf

Re: A Novel Approach For Computer Worm Control Using Decentralized Data Structures

#15
post #7

Haha, I had the same idea. The since (valid) transactions are passed freely to all nodes in the Bitcoin network, one can just use the network as a signed messaging platform. You don't need to query blockchain.info, all you need is a Bitcoin client that listens for incoming transactions. I've been writing an implementation on and off for a while now. The general idea is as follows: The botnet client connects to "n" Bi…

[deleted]

Re: A Novel Approach For Computer Worm Control Using Decentralized Data Structures

#18
post #16

Earlier quoted context omitted.

Are you planning to elaborate on why? Because just saying "This is stupid!" does not carry a lot of weight.

[deleted]

>Because it's too visible, hard to get out of any sort of modern corporate network

Valid point

>depends on propagation therefore extremely slow

0 confirmation transactions are instant

>public evidence of communications

Sure, but if obfuscated who's going to look? Even if encrypted with a symmetric key on the client, you'll need to reverse engineer the client. Packers and obfuscators can make your life very hard indeed. However I'm sure there's a way to did it with perfect foward secrecy (or at least an reasonable amount).

>additional constraints in the form of money spent for transactions

You don't need to pay for a c&c server any more, that's money saved.

>increased complexity on the implant and so on and so forth.

Sure

>In fact, I can't think of a single good reason why this would make a practical malware comm protocol.

How about completely anonymous, no c&c server to take down, and cannot be killed without killing Bitcoin with it?

Re: A Novel Approach For Computer Worm Control Using Decentralized Data Structures

#19
post #16

Earlier quoted context omitted.

Are you planning to elaborate on why? Because just saying "This is stupid!" does not carry a lot of weight.

[deleted]

Some reasons why I think this would be a good idea (as a BACKUP comms channel), though I admit I am no experts in botnets:

1) It only requires a handful of outgoing TCP connections. This is fine if you are targeting windows consumer boxes

2) It is near-impossible to take down this communications channel. If your regular C&C server gets raided/taken down then you can broadcast the new connection details using this

3) You only have to spend anything to make a new broadcast. If this were to be used as a backup C&C channel that would rarely happen, and it's fine if that were to be slow too.

4) Regarding complexity, the client will already be complex if you're going to be implementing crypto to verify commands which you should do anyway. I don't really see why complexity is a bad thing here either if it works fine.

You're right that the evidence is not really ideal, but many other comms channels used in the past have had that property, such as twitter accounts.

> There are far better ways to get this sort of reliability without shooting yourself in the foot by accepting all the handicaps I mentioned.

Do elaborate?

Re: A Novel Approach For Computer Worm Control Using Decentralized Data Structures

#20
post #18
post #16

Earlier quoted context omitted.

[deleted]

>Because it's too visible, hard to get out of any sort of modern corporate network Valid point >depends on propagation therefore extremely slow 0 confirmation transactions are instant >public evidence of communications Sure, but if obfuscated who's going to look? Even if encrypted with a symmetric key on the client, you'll need to reverse engineer the client. Packers and obfuscators can make your life very hard indee…

[deleted]
Post reply on HN