Pay attention to Cryptowall!
CryptoLocker might be pretty much off the radar. But Cryptowall is alive and kicking, and making the bad guys a ton of money. It mainly spreads by poisoned advertisements and hacked benign websites, and then sneaks its way onto the PCs of unsuspecting users by means of Silverlight, Flash and Java Exploits.
Somewhat unexpectedly, Java is NOT the most prominent for a change. It looks like the Silverlight sploits are currently the most successful.
If you're "had", Cryptowall encrypts all the files that you possible could want to keep (images, documents, etc), and then asks for a 500$ ransom. If you don't pay up quick, the ransom doubles. And after a while of not paying, well, the suckers delete the key. As far as we know, there is not way yet to recover the encrypted data, because the private key is not really present on the infected machine. I hope you have a recent backup.
Last week's batch of infections for example had "food.com" as a prominent source. As far as I can tell, they are cleaned up by now, but we have several samples in the database that show pages like http://www.food[dot]com/recipe/pan-fried-broccoli-226105, http://www.food[dot]com/recipe/barefoot-contessas-panzanella-salad-135723, etc, as the last referer before the exploit triggered.
The domains last week were following the pattern [a-f0-9]{6,8}\.pw and [a-f0-9]{6,8}\.eu, but this is obviously changing all the time. Still, it probably doesn't hurt to check your DNS or proxy logs for the presence of (especially) .pw domains. Yes, I had to look it up as well ... .pw is Palau. A bunch of islands in the South Pacific. It is safe to assume that most of the web sites with this extension are not actually about or in Palau.
More info: Ronnie has an outstanding write-up at http://phishme.com/inside-look-dropbox-phishing-cryptowall-bitcoins/ . Cisco's blog has a lot of IOCs: https://blogs.cisco.com/security/rig-exploit-kit-strikes-oil
Help your pilot fly!
What the Federal Aviation Administration (FAA) calls "novel and unusual" apparently entails some sort of direct network connectivity between the avionics (think: cockpit) and the passenger entertainment system (think: dude with his iPhone connected to the in-seat USB port) in the latest Boeing 737 models.
The good news is, if you get bored on your next flight, and the movies are all *meh*, you might be able to connect to the cockpit and help the pilot do his/her job. Pilots, these days, are all stressed out, and I'm sure they appreciate help from all the XBox and Nintendo pilots sitting in the main cabin! A completely new form of auto-pilot: Flying a plane through majority decision by the geeks in the cabin!
I wonder how many years we are away from a cross-platform virus that moves from Joe Bloe's PC at home, to his phone, to his car, to his tablet, to his airplane. I hope it never happens. But the "internet of things" manufacturers, especially the manufacturers of massive moving things, seem to be very keen to get us there.
Gimme your keys!
It doesn't take a lot of security savvy to realize that private keys used for things like SSH login probably should not be stored in the webroot of a web server. The physical world equivalent would be to place your house key under the doormat, and nobody does that, right?
Still, we are seeing an uptick of scans on web servers looking for such files that really shouldn't be present.
93.95.yyy.xx - - [09/Jun/2014:17:39:41 +0100] "HEAD /dsa HTTP/1.1" 404 124 "-" "-"
93.95.yyy.xx - - [09/Jun/2014:17:39:41 +0100] "HEAD /id_dsa HTTP/1.1" 404 124 "-" "-"
93.95.yyy.xx - - [09/Jun/2014:17:39:41 +0100] "HEAD /id_dsa.old HTTP/1.1" 404 124 "-" "-"
93.95.yyy.xx - - [09/Jun/2014:17:39:41 +0100] "HEAD /identity HTTP/1.1" 404 124 "-" "-"
93.95.yyy.xx - - [09/Jun/2014:17:39:41 +0100] "HEAD /id_rsa HTTP/1.1" 404 124 "-" "-"
93.95.yyy.xx - - [09/Jun/2014:17:39:41 +0100] "HEAD /id_rsa.old HTTP/1.1" 404 124 "-" "-"
93.95.yyy.xx - - [09/Jun/2014:17:39:41 +0100] "HEAD /key HTTP/1.1" 404 124 "-" "-"
93.95.yyy.xx - - [09/Jun/2014:17:39:41 +0100] "HEAD /key.priv HTTP/1.1" 404 124 "-" "-"
93.95.yyy.xx - - [09/Jun/2014:17:39:41 +0100] "HEAD /rsa HTTP/1.1" 404 124 "-" "-"
[...]
The scan looks for about 50 different file names that are commonly associated with SSH keys. In addition, it also probes for the presence of common Unix shell history files:
93.95.yyy.xx - - [09/Jun/2014:17:39:43 +0100] "HEAD /.bash_history HTTP/1.1" 404 124 "-" "-"
93.95.yyy.xx - - [09/Jun/2014:17:39:43 +0100] "HEAD /.history HTTP/1.1" 404 124 "-" "-"
93.95.yyy.xx - - [09/Jun/2014:17:39:43 +0100] "HEAD /.sh_history HTTP/1.1" 404 124 "-" "-"
One signature that the scans so far had in common is that the first request is always to "checknfurl123".
93.95.yyy.xx - - [09/Jun/2014:17:39:41 +0100] "HEAD /checknfurl123 HTTP/1.1" 404 124 "-" "-"
This is most likely a test to determine how the scanned server responds to requests for files that do not exist, so that false positives can be eliminated in the subsequent attempts to read the SSH keys. I am currently running a honeypotty to see what the scanners do next if the "HEAD" request comes back with an okay (200). No luck yet, so if you already have that bit of intel, please share via the comments below.
Comments
Anonymous
Dec 3rd 2022
9 months ago
Anonymous
Dec 3rd 2022
9 months ago
<a hreaf="https://technolytical.com/">the social network</a> is described as follows because they respect your privacy and keep your data secure. The social networks are not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go.
<a hreaf="https://technolytical.com/">the social network</a> is not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go. The social networks only collect the minimum amount of information required for the service that they provide. Your personal information is kept private, and is never shared with other companies without your permission
Anonymous
Dec 26th 2022
8 months ago
Anonymous
Dec 26th 2022
8 months ago
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> nearest public toilet to me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
Anonymous
Dec 26th 2022
8 months ago
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> nearest public toilet to me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
Anonymous
Dec 26th 2022
8 months ago
Anonymous
Dec 26th 2022
8 months ago
https://defineprogramming.com/
Dec 26th 2022
8 months ago
distribute malware. Even if the URL listed on the ad shows a legitimate website, subsequent ad traffic can easily lead to a fake page. Different types of malware are distributed in this manner. I've seen IcedID (Bokbot), Gozi/ISFB, and various information stealers distributed through fake software websites that were provided through Google ad traffic. I submitted malicious files from this example to VirusTotal and found a low rate of detection, with some files not showing as malware at all. Additionally, domains associated with this infection frequently change. That might make it hard to detect.
https://clickercounter.org/
https://defineprogramming.com/
Dec 26th 2022
8 months ago
rthrth
Jan 2nd 2023
8 months ago