This is a log of how this redirect looked like. This is not from CleverMining but from an user connecting to another coin-switching pool, but it shows how the redirect is done:
1: {"id": 292, "method": "mining.subscribe", "params": ["cgminer/3.7.2", "deadbeefcafebabe4152000000000000"]}
2: {"error": null, "id": 292, "result": [["mining.notify", "ae6812eb4cd7735a302a8a9dd95cf71f"], "f800476e", 4]}
3: {"params": [1024], "id": null, "method": "mining.set_difficulty"}
4: {"params": ["89b", "74842cdbfb648490f4cf5371a383a48504755768167e9b6dd920dc24b666219f", "01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff2703f25402062f503253482f0407292f5308", "0d2f7374726174756d506f6f6c2f000000000100c7354dbd1600001976a9148d6906222b82cd2b4b99d14bee6182084cab17fe88ac00000000", ["89d439d4c71e06c4f7632d4c5ab208022c23c51df58f29f4a5eb6d55c5065f57", "42d4ef5e17054a08298bb72c317262ea257df4472a13606c0c8e5207babe9b6e", "5d3ebf66acdc4cea8b8c6a7bf12ac46430de2fdb6d6300ea804e2bacca83851f", "bd3f92311678c4f72f69da3a786caa85f94fbb7ef0525c14f9be9e11ae6cff24", "259bf6b3c95bc7bd568dce6b8766b7ac63efc9ecdd4dff5f77dd351548cff654"], "00000002", "1b3326cb", "532f2907", true], "id": null, "method": "mining.notify"}
5: {"id": 293, "method": "mining.authorize", "params": ["removed", "d=1024"]}
6: {"error": null, "id": 1, "result": true}
7: {"error": null, "id": null, "method": "client.reconnect", "params": ["190.97.165.179",3333"]}
I numbered lines to be able to refer to them. What you see above is miner initiating its dialogue with the pool, so these are commands sent just after connecting to the pool. In this case miner must have been disconnected and then reconnected (trying to reconnect either to the same pool or to backup pool) - and this reconnected connection was hijacked somehow.
Messages coming from the pool (lines 2, 3, 4, 6, 7) are definitely NOT from CleverMining. They are also not from the pool which the above user was connected to, because:
Line 2: both CleverMining and the other pool use different subscription id format than sent by pool in line 2.
Line 3: both CleverMining and the other pool use 512 default difficulty and this pool sent 1024.
Line 2 & 3: both CleverMining and the other pool send lines in reverse order - send difficulty first, then send initial notify with subscription id
Line 4: both CleverMining and the other pool use different order of arguments when sending commands to miners (first id, then method, then params; here is first params, then method, then id).
Line 7: this is actual redirect request send by the fake pool.
The whole above communication is not a communication between miner and the pool which it intended to connect to. This fake pool clearly uses a different stratum software because its output is very different from what are using both CleverMining and the pool which the log should suppose to come from. (everything in the above log is consistent with how python stratum-mining server works, which we don't use).
So what happened here is:
1. Miner got disconnected from its legitimate pool.
2. It tried to reconnect, but was connected to a fake pool instead.
3. This fake pool immediately ordered it to reconnect to a different IP, effectively redirecting it to another pool.
4. The miner connected to 190.x address and started mining on a malicious pool.
The mystery is why user was connected to a fake pool after being disconnected from legitimate pool.
This is probably some kind of MITM attack as the user was connected to a fake pool after disconnection. The question is where this MITM attack was performed.
