61–70 of 71 posts
Earlier quoted context omitted.
Sounds like it would be more profitable to just lock out the device than encrypt the files, for its internet browsing value may exceed its file storage value.
It's much easier to recover from lock out (without losing data) than decrypting the file.
Evil Ransomware improvements we may see: 1. New address per machine (easier to detect payments made, hides profit total.) 2. Deterministic wallet stores all profit in a simple 12 word seed "password." 3. Phone numbers directly to bitcoin vendors. (people running insecure systems love phones.) 4. Phone number to tech support company that bills your credit card to walk you through paying the ransom. 5. Delayed symptoms…
"2. Deterministic wallet stores all profit in a simple 12 word seed "password." You don't want the seed distributed to all victims. There is risk it will be reverse engineered. There is a way to ge
Earlier quoted context omitted.
There's absolutely no reason that sending a link to someone should be able to pwn their box. There's no reason to make such fragile email systems.
What if they click the link, run the downloaded invoice.EXE, and enter their password when prompted? At a certain point, the user needs to be educated enough to avoid this. PDF/Office macros are a whole other topic though.
Evil Ransomware improvements we may see: 1. New address per machine (easier to detect payments made, hides profit total.) 2. Deterministic wallet stores all profit in a simple 12 word seed "password." 3. Phone numbers directly to bitcoin vendors. (people running insecure systems love phones.) 4. Phone number to tech support company that bills your credit card to walk you through paying the ransom. 5. Delayed symptoms…
according to the article, the balances of the bitcoin addresses collecting the ransoms are 15.13562354 BTC = $26410 13.78022431 BTC = $24045 5.98851225 BTC = $17361 Assuming $300 per ransom, this works out to a total of 226 victims who paid. this seems a little low compared to the huge amount of infected devices.
Earlier reports I'd heard said that this group was unprepared or poorly prepared to handle the incoming ransom. Many of these ransomware campaigns use a fully automated mechanism to deliver keys upon payment, this group did not.
Notable that he calls the "kill-switch" a "mistake". For example, Chrome does the same thing. When it starts it checks for some presumably non-existant domain name.
Yes, but the key difference is that chrome uses a randomly generated domain name, while the ransomware has it hardcoded.
Anyway, how is the difference significant?
A localhost cache can point at a custom root.zone. The user can make her own authoritative nameserver assignments for any given zone or domain. Zone files can contain wildcards.
Responses can also be rewritten on the fly.
The end user can exercise full control over what is and is not a "valid" domain name. She can prevent her applications from ever receiving an "NXDOMAIN" response.
Maybe I am missing something but this "test" seems brittle; it only tests ICANN DNS.
Earlier quoted context omitted.
I think this venn diagram explain part of the problem: https://www.trustar.co/wp-content/uploads/2017/05/WannaCryVe...
How did the 300M USD CryptoWall cashed that much?
http://thehackernews.com/2015/10/cryptowall-ransomware.html
That averages out at $800 per infection compared to about $0.30 per infection from WannaCry. I suspect there are other factors at play here (was all the revenue from ransoms? were that target systems different? are people hardening in their resolve not to pay these ransoms?).
Earlier quoted context omitted.
"Back in the 1990s MS was a good company." Umm, isn't that precisely the period when they were charged with antitrust violations? Such a short memory we have.
I think the OPs context for "good company" is "good company _for coders/hackers_". You can have a company behaving in an anti-trustworthy way, but their software still be _good_. Also, their antitrust violations was due to the Windows OS and anti-competitive behaviours, if i'm not mistaken? If so, then this is not really relevant to their software or OP's post, but more their business approach of locking out competit…
Earlier quoted context omitted.
What if they click the link, run the downloaded invoice.EXE, and enter their password when prompted? At a certain point, the user needs to be educated enough to avoid this. PDF/Office macros are a whole other topic though.
There's a really big gap there. Look at chromeOS - you can click a lot more email links on that OS without getting ransomware'd.
Earlier quoted context omitted.
There's a really big gap there. Look at chromeOS - you can click a lot more email links on that OS without getting ransomware'd.
Is it because the OS is inherently more secure, or because the malicious code is not written for that OS?