I Inspected My Take-Home Interview Project. It Was a Whole Operation
70 points by trousers
70 points by trousers
I thought I'd check the given IP address, 45.61.164.38. It's hosted by RouterHosting under Cloudzy, AS14956, and I don't see overlap with the wiki spam blocklist tabs I usually keep open. Reporting the abuse might be helpful?
14 hours later: still up, still offering the same malware.
I hadn't done it myself yet! I'll do it shortly. I guess I'd hoped the author would pick it up psychically.
Edit: first, I reached out to the author on, sigh, LinkedIn, to check if anything more could be learned from leaving the server up. It's almost midnight in Hyderabad, so, I don't have high expectations.
I feel sad, i never got targeted by personalized scam campaigns, only generic spam and obviously real sub par job offers. Not even medium effort phishing.
Claude’s guardrails are incredibly annoying.
If you’re actually doing something malicious you have more incentive to figure them out and work around them, but for regular people who want to understand things they go off super easy and there is no incentive to keep trying.
I've been on the market for quite a while and there are many flavours of nonsense going on. Sometimes they want you to build a deliverable for them for free which is crazy. Other times they try to hack you -- this seems like a glaring example of that. Sad. But good on you for detecting this before getting bitten.
As a general rule, I refuse take-homes or requests to build deliverables. Instead, I offer 2 things:
If these offers get refused, I move on because the refusal sets of my BS detector. Maybe there are false positives, but the amount of true positives captured is surely an order of magnitude higher.
While it can be dejecting to exit an interview process for this reason, I keep coming back to my new personal mantra, which is something like:
"If evidence of my competence is inadmissible in the court of this enterprise, I do not want to practice there"
Although this is a great writeup of an interesting finding, continuing the analysis in a dedicated VM as soon as you spot the presence of malware is an approach I'd still consider pretty risk-tolerant. The author (and many other pentesters) is/are very clever, but a bit of paranoia really helps to avoid a moment of inattentiveness turning into a lot of pain...
Nonetheless, this is an interesting writeup!
hardhat could be used for multiple reasons. It allows you to connect to a remote Ethereum RPC or launch a local but simulated fork (hence almost 0 resource) of a one. There are two apparent reasons I could think why would someone want to do this: 1. a simple private key stealer for unprotected wallets and 2. a MITM attack for hardware wallets. The former kind you can find from many Minecraft mods etc., this is nothing too sophisticated and hardhat would only be necessary (that I can think of) if you want to dry-run transactions first. I.e., if you already have the private key, the hacker can just initiate the attack whenever without user interaction. For user interaction, you'd need hardhat for the latter case. When you interact with Ethereum e.g. via a browser extensions, you need to be connected with a RPC. All browser extensions provide the connection via some hosted server. You send signed transactions to them, and they broadcast those to the network. A MITM attack here could allow the hacker to phish for signing a malicious transaction by rewriting the payload that gets signed by the hardware wallet. E.g., the user is interacting with some legit application on their browser, and makes a transaction, the RPC server picks that up but returns a malicious payload, the user does not check it properly because they think they are interacting with a trusted website, and the malicious payload gets signed and executed by the hacker.