How I Got Hacked: A Warning about Malicious PoCs

Comments

• Deceptichum@quokk.au ⁨1⁩ ⁨day⁩ ago

  I feel like PoC wasn’t the most clarifying of initials for a title here.

  source

  • Penguincoder@beehaw.org ⁨1⁩ ⁨day⁩ ago

    Sorry for that, this is the technology community though. PoC in tech has a different meaning than others, being Proof of Concept. Each community or in groups have their own acronyms even if it overlaps others. I did not think that acronym in this context needed clarification.

    source
• jarfil@beehaw.org ⁨18⁩ ⁨hours⁩ ago

  Never, EVER, do anything security related while sleep deprived, drunk, high, having sex, or all of the above.

  After that… no, don’t trust. Zero trust.

  There are basic hygiene measures to run anything related to any exploit — including “just” PoCs — depending on how risky a total pwn would be:

  • container
  • VM
  • separate machine
  • airgapped
  • airgapped in a faraday cage (tinfoil works wonders to kill WiFi, a cheap DBV stick turned SDR is great for making sure).

  Reading through the code is nice, and should be done anyway from an educational point of view… but even when “sure”, basic hygiene still applies.

  Keeping tokens in one VM (or a few), while running the exploit in another, is also a good idea. Stuff like ”Windows → WSL2 → Docker", works wonders (but beware of VSCode’s pass-through containers). Bonus points if passkeys and a fingerprint reader get involved. Extra bonus points for logging out before testing (if it asks to unlock any passkey… well, don’t), then logging out again afterwards.

  ---

  What I’m not so sure about, is deleting the siphoned data without alerting the potential victims. Everyone kind of failed at security, but still. A heads up to rotate all keys, would be nice.

  source
• Moonrise2473@feddit.it ⁨1⁩ ⁨day⁩ ago

  The repo is about an exploit and then hundreds of people just run the script? Seems interesting

  source

  • t3rmit3@beehaw.org ⁨1⁩ ⁨day⁩ ago

    Not that unusual, unfortunately. The infosec community relies on researchers publishing PoC exploits in order for people to determine whether they’re affected or not, but that trust in PoCs can obviously be exploited.

    Not everyone has the time or knowledge to develop their own PoCs, but you should definitely not use one if you can’t understand the PoC, which is unfortunately rather common.

    source
• LedgeDrop@lemm.ee ⁨1⁩ ⁨day⁩ ago

  I’m sorry this happened, but it seems rather reckless of the author to be running “Malicious PoCs” on their “daily driver” (re: the PC they use for everything).

  If I was in the habit of running “Malicious PoCs”, you can be certain it would be isolated from the rest of my system. This could be in a sandbox or a vm. Heck, just created a dedicated (one time use) “new user” would have been better than "Hey, let me just download and run some random shell script. Oh, it needs root? No problem!

  source
• t3rmit3@beehaw.org ⁨1⁩ ⁨day⁩ ago

  Good writeup!

  Definitely never good to run PoCs sight unseen; mostly not because of this kind of situation, but even just because different PoCs will have different results, and you need to know what to expect.

  Also, if you see any level of obfuscation in PoC code, it’s more than likely malicious.

  source
• tal@lemmy.today ⁨1⁩ ⁨day⁩ ago

  This does kind of drive home some points. Obviously, once malware is running with your full user permissions, all bets are off. But there are some things that could have mitigated harm here.

  The malware wasn’t just mining cryptocurrency—it was also stealing as much sensitive information as possible. It collected:

  • SSH keys from ~/.ssh/

  If you password-protect your SSH keys with a decent password, it will help address this. Now, the problem is that any software that can get at your SSH keys probably has a shot at also setting up some kind of keylogger system, but at least it makes it not a one-step process.

  • Shell history from .bash_history and .zsh_history

  Avoiding using sensitive data as command line arguments is a good habit to be in. They’re visible systemwide to all processes on a normal system, which already creates a meaningful leak on multiuser systems, and various pieces of command-line software go out of their way to avoid having passwords and the like passed on the command-line.

  • AWS and Azure credentials from ~/.aws/ and ~/.azure/

  Not familiar with the current forms of these, but I bet that they provide some way not to store unencrypted credentials there.

  • Environment variables and system information

  Environment variables are a really good place not to put sensitive data, because software that crashes and uploads a crash dump to God-knows-where will also tend to dump environment variables along with it, as it’s important debugging information. Storing credentials in an environment variable is not a good idea.

  • Lists of files in my home directory

  source

  • Scrath@lemmy.dbzer0.com ⁨1⁩ ⁨day⁩ ago

    If you shouldn’t use sensitive information as command line arguments and also avoid environment variables for passwords, how should you pass such data to programs short of setting up a configuration file?

    source

    • tal@lemmy.today ⁨1⁩ ⁨day⁩ ago

      For the command line, do what OpenSSH does, take passwords on terminals.

      For environment variables, the issue is passing them to all programs; you don’t want to put credentials in a .bashenv or similar.

      source