4 ms·

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

by tokenizerrr 12y ago

deleted 12y ago
[deleted]
- verroq 12y ago
  >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?
  - deleted 12y ago
    [deleted]
- tokenizerrr 12y ago
  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?
deleted 12y ago
[deleted]

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

deleted 12y ago

[deleted]

verroq 12y ago
>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?
- deleted 12y ago
  [deleted]
tokenizerrr 12y ago
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?

deleted 12y ago

[deleted]