5 ms·

New 'OtterCookie' malware used to backdoor devs in fake job offers

can16358p 2y ago
Something similar happened to me: got a job offer many months ago from someone on LinkedIn that I don't know... though these things happen a lot. My title back then had web3 and Solidity developer in the name. He sent me the link to a Git repo for an NFT marketplace, a simple React app. He told me that the previous dev quit and someone needs to complete the unfinished project. I downloaded the code but opened in a VM, which turned out to be one of the best decisions of my life without even realizing it. When I ran the app some parts seemed broken as expected everything was otherwise normal. He then asked me that whether I'm running in a VM or not and some features wouldn't work in a VM and I should have ran on my actual computer. It was an immediate red flag (why would a React app need that?). I checked running processes on the VM and saw a Python instance. When I examined the opened files it pointed to a suspicious file, and it was a fresh VM and nothing in the project setup needs Python for anything. Then I zipped the project, sent it to ChatGPT and asked about malware, and it found a totally obfuscated dev-targetting malware-downloading script disguised as error handler middleware. If I ran it on my machine, it could have stolen at least a thousand bucks from my local crypto wallets: I checked the payload code via HTTP interception and realized that the script sends any private keys for crypto wallets to its own server, and I'd never be sure of my system again anyway. I've warned the hosting company (though it seemed like a very cheap and sketchy one anyway), and I found out that the person on LinkedIn has blocked me in the meantime. These are very real threats, be careful.
- Loughla 2y ago
  Remember when getting viruses required you to be on 2chan or sketchy free porn or font websites? Those were the days.
  - mathgeek 2y ago
    While these were the “obvious” high risk sites, running unknown executables from someone you “trust” has been an attack vector for as long as code has been shareable. It’s what is being referenced every time a film uses the “plug this into the server” trope for decades now.
  - bagels 2y ago
    Because of ad networks, you didn't even need to visit a disreputable part of the Internet. The virus was delivered via ads. The reason I won't internet without ad blockers.
    - morkalork 2y ago
      Does this happen anymore? I feel like if one had knowledge of javascript/image/whatever zero day exploit, there would be more profitable uses for it than blowing it spamming random people via an ad network. OP's example is a much lower hanging fruit, you don't need to have a fancy browser exploit if you can just trick someone into running your code. Just like all the cracked video games you can download that are loaded with viruses.
      - bagels 2y ago
        Referring to happenings 20 years ago (to go along with the GP "remember when") edit: 15 years ago NY Times reporting on how they infected people's computers with malicious drive-by ads: https://archive.ph/ZNp5 https://archive.ph/ZNp5
  - redwall_hp 2y ago
    I remember people opening emails with file.jpg.exe attachments and major ad networks distributing Flash banners that would infect a machine just from visiting sites as high profile as the New York Times.
- cmehdy 2y ago
  This seems very similar to yesterday's article about North Korea running similar shenanigans via LinkedIn[0]. Probably good to make it the norm to run these things in a VM. I doubt this requires running on a completely different host yet, given the simplicity of the code. [0] Analyzing North Korean Malware | https://news.ycombinator.com/item?id=42516568 https://news.ycombinator.com/item?id=42516568
  - can16358p 2y ago
    Yes, while this is not exactly the same, the code and general logic is eeriely similar to what was sent to me. One of them is likely a fork of the other.
- buran77 2y ago
  > He then asked me that whether I'm running in a VM or not and some features wouldn't work in a VM and I should have ran on my actual computer In the past I would have had a physical machine ready to do tests where I expected VM/hypervisor detection code. Just wipe, rinse, and repeat as needed. The reason I stopped doing this and also deeply dislike UEFI (or at least the way it works in practice) is that I can never trust the physical computer if I do happen to run such untrusted code on my physical machine even just once. UEFI rootkits are persistent and damn hard to detect. Some days I think I should run everything in a VM.
  - password4321 2y ago
    > Some days I think I should run everything in a VM. So does Qubes, and they explain why they use the bare-metal Xen hypervisor (no full host OS): https://www.qubes-os.org/faq/#how-does-qubes-os-compare-to-running-vms-in-a-conventional-os https://www.qubes-os.org/faq/#how-does-qubes-os-compare-to-r...
prophesi 2y ago
The report[0] it links to goes into more detail (in Japanese), and gives the file hash values and domains it accesses. [0] https://jp.security.ntt/tech_blog/contagious-interview-ottercookie https://jp.security.ntt/tech_blog/contagious-interview-otter...
deleted 2y ago
[deleted]

Something similar happened to me: got a job offer many months ago from someone on LinkedIn that I don't know... though these things happen a lot. My title back then had web3 and Solidity developer in the name. He sent me the link to a Git repo for an NFT marketplace, a simple React app. He told me that the previous dev quit and someone needs to complete the unfinished project. I downloaded the code but opened in a VM, which turned out to be one of the best decisions of my life without even realizing it. When I ran the app some parts seemed broken as expected everything was otherwise normal. He then asked me that whether I'm running in a VM or not and some features wouldn't work in a VM and I should have ran on my actual computer. It was an immediate red flag (why would a React app need that?). I checked running processes on the VM and saw a Python instance. When I examined the opened files it pointed to a suspicious file, and it was a fresh VM and nothing in the project setup needs Python for anything. Then I zipped the project, sent it to ChatGPT and asked about malware, and it found a totally obfuscated dev-targetting malware-downloading script disguised as error handler middleware. If I ran it on my machine, it could have stolen at least a thousand bucks from my local crypto wallets: I checked the payload code via HTTP interception and realized that the script sends any private keys for crypto wallets to its own server, and I'd never be sure of my system again anyway. I've warned the hosting company (though it seemed like a very cheap and sketchy one anyway), and I found out that the person on LinkedIn has blocked me in the meantime. These are very real threats, be careful.

Loughla 2y ago
Remember when getting viruses required you to be on 2chan or sketchy free porn or font websites? Those were the days.
- mathgeek 2y ago
  While these were the “obvious” high risk sites, running unknown executables from someone you “trust” has been an attack vector for as long as code has been shareable. It’s what is being referenced every time a film uses the “plug this into the server” trope for decades now.
- bagels 2y ago
  Because of ad networks, you didn't even need to visit a disreputable part of the Internet. The virus was delivered via ads. The reason I won't internet without ad blockers.
  - morkalork 2y ago
    Does this happen anymore? I feel like if one had knowledge of javascript/image/whatever zero day exploit, there would be more profitable uses for it than blowing it spamming random people via an ad network. OP's example is a much lower hanging fruit, you don't need to have a fancy browser exploit if you can just trick someone into running your code. Just like all the cracked video games you can download that are loaded with viruses.
    - bagels 2y ago
      Referring to happenings 20 years ago (to go along with the GP "remember when") edit: 15 years ago NY Times reporting on how they infected people's computers with malicious drive-by ads: https://archive.ph/ZNp5 https://archive.ph/ZNp5
- redwall_hp 2y ago
  I remember people opening emails with file.jpg.exe attachments and major ad networks distributing Flash banners that would infect a machine just from visiting sites as high profile as the New York Times.
cmehdy 2y ago
This seems very similar to yesterday's article about North Korea running similar shenanigans via LinkedIn[0]. Probably good to make it the norm to run these things in a VM. I doubt this requires running on a completely different host yet, given the simplicity of the code. [0] Analyzing North Korean Malware | https://news.ycombinator.com/item?id=42516568 https://news.ycombinator.com/item?id=42516568
- can16358p 2y ago
  Yes, while this is not exactly the same, the code and general logic is eeriely similar to what was sent to me. One of them is likely a fork of the other.
buran77 2y ago
> He then asked me that whether I'm running in a VM or not and some features wouldn't work in a VM and I should have ran on my actual computer In the past I would have had a physical machine ready to do tests where I expected VM/hypervisor detection code. Just wipe, rinse, and repeat as needed. The reason I stopped doing this and also deeply dislike UEFI (or at least the way it works in practice) is that I can never trust the physical computer if I do happen to run such untrusted code on my physical machine even just once. UEFI rootkits are persistent and damn hard to detect. Some days I think I should run everything in a VM.
- password4321 2y ago
  > Some days I think I should run everything in a VM. So does Qubes, and they explain why they use the bare-metal Xen hypervisor (no full host OS): https://www.qubes-os.org/faq/#how-does-qubes-os-compare-to-running-vms-in-a-conventional-os https://www.qubes-os.org/faq/#how-does-qubes-os-compare-to-r...

prophesi 2y ago

The report[0] it links to goes into more detail (in Japanese), and gives the file hash values and domains it accesses. [0] https://jp.security.ntt/tech_blog/contagious-interview-ottercookie https://jp.security.ntt/tech_blog/contagious-interview-otter...

deleted 2y ago

[deleted]