Home Tags Cron

Tag: Cron

Russian raids sweep up 20 malware scum

Cron job aborted after crims scoop ₽50m and share it to 6,000 bank accounts The Russian Interior Ministry has announced the arrest of 20 people following raids related to a malware campaign dubbed “Cronrdquo; emptying victims' bank accounts.…

Russian ‘Cron’ Cyber Gang Arrested for Raiding Bank Accounts

Russian authorities arrest a group of 16 hackers who allegedly were attacking banks in their native country via mobile malware, nixing plans for their global expansion.

RHBA-2016:2125-1: redhat-virtualization-host bug fix and enhancement update for RHV 4.0.4-1

Updated redhat-virtualization-host packages are now available. The redhat-virtualization-host packages provide the Red Hat Virtualization Host.These packages include redhat-release-virtualization-host, ovirt-node, andrhev-hypervisor. Red Hat Virtualiz...

10 decisions you'll face when deploying a honeypot

Honeypots provide the best way I know of to detect attackers or unauthorized snoopers inside or outside your organization. For decades I've wondered why honeypots weren't taking off, but they finally seem to be reaching critical mass.
I help a growing number of companies implement their first serious honeypots -- and the number of vendors offering honeypot products, such as Canary or KFSensor, continues to grow. If you're considering a honeypot deployment, here are 10 decisions you'll have to make. 1. What's the intent? Honeypots are typically used for two primary reasons: early warning or forensic analysis.
I'm a huge proponent of early-warning honeypots, where you set up one or more fake systems that would immediately indicate maliciousness if even slightly probed. Early-warning honeypots are great at catching hackers and malware that other systems have missed. Why? Because the honeypot systems are fake -- and any single connection attempt or probe (after filtering out the normal broadcasts and other legitimate traffic) means malicious action is afoot. The other major reason companies deploy honeypots is to help analyze malware (especially zero days) or help determine the intent of hackers. In general, early-warning honeypots are much easier to set up and maintain than forensic analysis honeypots. With an early-warning honeypot, when you detect a probe or connection attempt, the mere connection attempt gives you the information you need, and you can follow the probe back to its origination to begin your next defense. Forensic analysis honeypots, which can capture and isolate the malware or hacker tools, are merely the beginning of a very comprehensive analysis chain.
I tell my customers to plan on allocating several days to several weeks for each analysis performed using a honeypot. 2. What to honeypot? What your honeypots mimic is usually driven by what you think can best detect hackers earliest or best protect your "crown jewel" assets. Most honeypots mimic application servers, database servers, web servers, and credential databases such as domain controllers. You can deploy one honeypot that mimics every possible advertising port and service in your environment or deploy several, with each one dedicated to mimicking a particular server type.
Sometimes honeypots are used to mimic network devices, such as Cisco routers, wireless hubs, or security equipment. Whatever you think hackers or malware will most likely to attack is what your honeypots should emulate. 3. What interaction level? Honeypots are classified as low, medium, or high interaction. Low-interaction honeypots only emulate listening UDP or TCP ports at their most basic level, which a port scanner might detect.

But they don't allow full connections or logons. Low-interaction honeypots are great for providing early warnings of malicious behavior. Medium-interaction honeypots offer a little bit more emulation, usually allowing a connection or logon attempt to appear successful.

They may even contain basic file structures and content that could be used to fool an attacker. High-interaction honeypots usually offer complete or nearly complete copies of the servers they emulate.

They're useful for forensic analysis because they often trick the hackers and malware into revealing more of their tricks. 4. Where should you place the honeypot? In my opinion, most honeypots should be placed near the assets they are attempting to mimic.
If you have a SQL server honeypot, place it in the same datacenter or IP address space where your real SQL servers live.
Some honeypot enthusiasts like to place their honeypots in the DMZ, so they can receive an early warning if hackers or malware get loose in that security domain.
If you have a global company, place your honeypots around the world.
I even have customers who place honeypots that mimic the CEO's or other high-level C-level employees' laptops to detect if a hacker is trying to compromise those systems. 5.

A real system or emulation software? Most honeypots I deploy are fully running systems containing real operating systems -- usually old computers ready for retirement. Real systems are great for honeypots because attackers can't easily tell they're honeypots. I also install a lot of honeypot emulation software; my longtime favorite is KFSensor.

The good ones, like KFSensor, are almost "next, next, next" installs, and they often have built-in signature detection and monitoring.
If you want low-risk, quick installs, and lots of features, honeypot emulation software can't be beat. 6. Open source or commercial? There are dozens of honeypot software programs, but very few of them are supported or actively updated a year after their release.

This is true for both commercial and open source software.
If you find a honeypot product that's updated for longer than a year or so, you've found a gem. Commercial products, whether new or old, are usually easier to install and use. Open source products, like Honeyd (one of the most popular programs) are usually much harder to install, but often far more configurable. Honeyd, for example, can emulate nearly 100 different operating systems and devices, down to the subversion level (Windows XP SP1 versus SP2 and so on), and it can be integrated with hundreds of other open source programs to add features. 7. Which honeypot product? As you can tell, I'm partial to commercial products for their feature sets, ease of use, and support.
In particular, I'm a fan of KFSensor. If you choose an open source product, Honeyd is great, but possibly overly complex for the first-time honeypot user.
Several honeypot-related websites, such as Honeypots.net, aggregate hundreds of honeypot articles and link to honeypot software sites. 8. Who should administer the honeypot? Honeypots are not set-and-forget it solutions -- quite the opposite. You need at least one person (if not more) to take ownership of the honeypot.

That person must plan, install, configure, update, and monitor the honeypot.
If you don't appoint at least one honeypot administrator, it will become neglected, useless, and at worst, a jumping-off spot for hackers. 9. How will you refresh the data? If you deploy a high-interaction honeypot, it will need data and content to make it look real.

A one-time copy of data from somewhere else isn't enough; you need to keep the content fresh. Decide how often to update it and by what method. One of my favorite methods is to use a freely available copy program or a copy commands to replicate nonprivate data from another server of a similar type -- and initiate the copy every day using a scheduled task or cron job.
Sometimes I'll rename the data during the copy so that it appears more top secret than it really is. 10. Which monitoring and alerting tools should you use? A honeypot isn't of any value unless you enable monitoring for malicious activity -- and set up alerts when threat events occur.

Generally, you'll want to use whatever methods and tools your organization routinely uses for this.

But be warned: Deciding what to monitor and alert on is often the most time-consuming part of any honeypot planning cycle.

IPv6 servers beat IPv4 in security — for now

Security company Sucuri CTO Daniel Cid recently conducted a small experiment: How long would it take for attackers brute-forcing SSH accounts to compromise IPv4 and IPv6 servers? While the IPv4 servers fell within minutes -- no surprise there -- none of the IPv6 servers got hit. Not a single one. As part of the experiment, Cid configured five IPv4 servers and five IPv6 servers with open SSH ports across two cloud hosting providers, Digital Ocean and Linode.

Attackers typically run through a list of common passwords to find the user account using that string, so all the test servers had "password" as the root password. It didn't take long for the first server to be compromised -- just 12 minutes, in fact.
It took the attacker only 20 seconds to brute-force the SSH password.

The first server to fall was one of the IPv4 ones, and the remaining four followed suit within minutes of the first.

The IPv6 servers, on the other hand, remained intact.

After one week, none of them had been scanned, probed, or attacked, much less compromised. The IPv6 servers didn't benefit from some built-in security feature or from any inherent security superiority over the older protocol.

The attackers just didn't find them. Years after the last IPv4 address blocks were allocated to regional Internet registries and the world proclaimed there were no more IPv4 addresses left, IPv6 servers are few and remain relatively obscure.
Some criminals may be targeting IPv6 servers, but they are still small in number compared to the attack volume against IPv4 systems. It also helps that the larger address space (2^128 potential addresses to IPv4's 2^32) makes it harder to scan and find potential IPv6 targets.
In contrast, it's easy to find scan lists of IPv4 addresses with IP ranges of several well-known hosting providers, through various online sources.

These lists provide attackers with a starting point in finding IPv4 servers. "What we can draw from this is that the obscurity of IPv6 helps to minimize the noise of attacks," Cid said. As an aside, the attackers who compromised the IPv4 servers didn't waste any time.

As soon as they were in, they downloaded three distributed denial-of-service attack scripts -- dos.py, down.pl and viteza.py -- from three Romanian sites and modified init files to load the Linux DDoS toolkit Linux/Xor.DDoS during boot.

To make sure they didn't lose control over the machine, the attackers also installed backdoors and set up an hourly cron job to re-enable the malware if it gets removed. While all five IPv4 servers were injected with the same malware, only one appeared to have been used in an active campaign.

Digital Ocean detected one of the servers participating in a massive 800+ Mbps SYN packet flood against three customers on a Chinese IP address before it disabled networking on the problematic droplet. "We didn't expect attackers to use it so quickly after the initial compromise," Cid wrote, noting they needed to be more careful with these experiments. Networking should have been disabled as soon as the machines were compromised. Bottom line, administrators shouldn't underestimate how quickly attackers move.
It may be tempting to save time by setting up servers with a weak or default password and plan to change it to a secure password later.

But it isn't worth the potential time savings when they can lose control of the box within a 15-minute span. Attackers are clearly still using SSH brute-force attacks, so servers need strong credentials from the start. Using IPv6 servers keeps the attackers at bay for now, but that doesn't excuse bad habits.
Servers should already have strong credentials and configure all the security mechanisms before they are connected online.

There is no time for later.