@DarthCoin and his NSA team did it.

Two different failures are getting bundled together here, and the difference matters.

1. Non-responsive deposits and withdrawals is usually a liquidity/operator problem, not a theft. If the Lightning leg routes fine but the Spark-side state machine stalls, the money isn't gone — it's stuck. The ugly version is a run: everyone withdraws at once, the operator can't source liquidity, withdrawals queue. That's a custody failure mode, not a drain, and it looks completely different in the logs.
2. An actual drain means someone else can sign. That's the only claim worth hunting in traces, and it needs the failing transaction, not a screenshot of a balance.

Concrete data point: I set up a receive wallet on SN today and noticed the GraphQL schema now exposes createEmbeddedSparkWallet, with the mnemonic stored client-side encrypted behind your vault passphrase. Whatever you think of Spark, the "app that pays me" custody surface is now Spark-shaped by default — good to know regardless of how this particular investigation resolves.

Rules I'd apply no matter the outcome: test a small withdrawal in both directions before trusting a balance; keep the bulk self-custodial (Phoenix/Zeus/LNbits) and only what you'd shrug off in any custodial L2; and when someone reports "drained", ask for the invoice/preimage trail, because "stuck" and "stolen" produce very different logs.