Security experts at Secureworks have revealed that vulnerability exploitation has accounted for 52% of ransomware incidents investigated by the company over the past 12 months. This makes it the number one initial access vector for attackers, according to a new report published by the company.

As an annual report, the security firm's State of the Threat report is compiled based on the insight gathered from the anti-terrorism unit of the organization over the past year.

A leading ransomware researcher has found that last year, ransomware actors mainly used vulnerabilities found in systems exposed to the Internet to increase their effectiveness, rather than to take advantage of credentials – often associated with the compromise of Remote Desktop Protocol (RDP), and using malicious emails.

Reports suggested that this shift in tactics may directly result from a significant imbalance between the capabilities of threat actors and network defenders. This imbalance may explain this shift in tactics.

At the same time as threats are rapidly weaponizing newly discovered vulnerabilities, developers of offensive security tools (OSTs) are also driven by the need to generate profit or keep their tools relevant – to implement updated exploit code as soon as possible, the report illustrated. 

A lot of people often overlook the fact that responsible disclosure is often about not having to wait for patches to become available. Even if a patch is available, the process of patching a vulnerability in an enterprise environment is far more complicated and much slower than the process for threat actors or OST developers of weaponizing publicly accessible exploit code.

As a result, vulnerability management teams must also take precautions against the persistent threat of credential-based attacks. In a recent report, Secureworks reported a 150% growth in the use of info-stealers that are designed to grab credentials from networks and gain access to them in an attempt to steal sensitive information.

There has been an investigation launched by an anti-virus vendor on a single day in June, during which it claimed to have observed over 2.2 million credentials, which were collected by criminals who stole information and made them available for sale on an underground platform.

According to Secureworks, ransomware continues to represent the number one threat to global organizations, accounting for more than a quarter of the attacks analyzed by the company. Among the threats that have been reported, most of them have been linked to Russian cybercrime groups.

So far this year, the good news is that the median dwell time of attackers has dropped from 22 days in 2021 to 11 days. This is a decrease of two days from last year, but it still leaves attackers with plenty of time to steal data from organizations and deploy the payloads for ransomware attacks.

Safeguarding your systems from malware attacks includes simple yet effective measures like

• Never click on unknown or unauthorized links or stores.

• Never input your personal information on unofficial stores or websites.

• Never click on any unknown attachments on emails.

• Never plug into any unknown USB sticks.

• Never download any software or application from unauthorized sources.

• Always keep your systems up-to-date.

• Always work under VPN security while using public wi-fi.

 

To ensure that the vulnerabilities do not get exploited, you need to identify and address them as soon as possible. Keeping track of your vital systems and their security is impossible without implementing an effective vulnerability management system (VM). 

Choosing the right VM tools is important as they provide accuracy, guidance in the right directions, and efficiency, to help your team in dealing with the most critical vulnerabilities. Once you establish a scalable and sustainable VM program you will be capable of defending your systems from ransomware attacks.

On December 9, 2021, a (now-deleted) tweet pointing to a 0-day proof of concept (PoC) exploit for the Log4Shell vulnerability on GitHub set the internet ablaze, sending businesses rushing to mitigate, patch, and patch again as other PoCs surfaced. 

Public vulnerability disclosure – that is, revealing to the world the existence of a bug in a piece of software, a library, an extension, or another piece of software, and releasing a proof-of-concept (PoC) that exploits it – occurs frequently for vulnerabilities in a wide range of software, from the most esoteric to the most mundane (and widely used). 

Threat actors are the only ones who benefit from the public disclosure of 0-day PoCs, as per research and experience, because it puts enterprises in the awkward position of needing to remediate the issue without having anything solid to mitigate it with (i.e., a vendor's patch). 

There are several different types of responsible vulnerability disclosure systems available today. Some companies have an official vulnerability disclosure programme while others arrange and operate it through crowdsourced platforms. Companies typically offer money for information concerning flaws in their products (also known as "bug bounties"). 

Those disclosures usually follow a set of steps, and vendor patches have clearly stated release dates so that users have plenty of time to install them (90 days is the accepted standard for this). 

When the Log4Shell vulnerability was announced publicly, the disclosure procedure was already underway (as evidenced by the pull request on GitHub that appeared on November 30). The following is the timeline of the disclosure, according to information provided by the Apache Software Foundation:

While user comments on the Apache Log4j GitHub project page expressed dissatisfaction with the timeliness of the update, this is to be expected when it comes to patching vulnerabilities - as everyone keeps pointing out, after all, the patch was developed by volunteers. 

There could be valid and logical reasons for releasing a 0-day proof-of-concept. The most prevalent of these is the breakdown of the vulnerability disclosure process: the vendor may not be or cease to be responsive, may judge the vulnerability to be minor enough to warrant a repair, or may take too long to fix it – or any combination of the above. 

In situations like these, security researchers frequently decide to make the PoC public for the "common good," i.e. to force vendors to release a patch quickly. Other factors could include publicity (especially if the researcher is associated with a security vendor) – nothing attracts more press attention than zero-day proof-of-concept exploits for a widely used piece of software, especially if no patch is available. 

However, it should be noted that the evidence against publishing proof-of-concept exploits is now substantial and overwhelming. According to a study conducted by Kenna Security, sharing proof-of-concept attacks mostly assists attackers. A presentation at Black Hat several years ago walked through the lifecycle of zero-days and how they were released and exploited, demonstrating that if proof-of-concept exploits aren't publicly disclosed, the vulnerabilities in question aren't discovered for an average of 7 years by anyone else (threat actors included).

Unfortunately, during the log4j scramble, this was discovered a little too late. Although the initial tweets and disclosures were quickly withdrawn, the harm had already been done. Even the most recent revelation, which resulted in the release of patch 2.17.1, generated so much criticism from the security community that the researcher apologized publicly for the publication's bad timing. 

It's encouraging to see that public disclosure of PoC exploits is becoming more common. Researchers who choose to jump the gun need to be criticized, but all must all work together to ensure that more rigorous disclosure mechanisms are in place for everyone so that the public PoC scenario is avoided the next time a vulnerability like Log4Shell is uncovered.

Sharing has become a thing with cyber-criminals and their malware mechanisms. Reportedly, LeetHozer botnet was found to have similar attack tactics as that of the Mootbot malware family. Researchers have reasons to think that the party that created the Moobot also could be the ones who created the LeetHozer.

Per researchers, the LeetHozer botnet has been counting on other kinds of malware for a little bit of sharing here and there. Per sources, it has in the past used the loader and reporter system that the Mirai uses.

Apparently, despite using the same mechanisms as Mirai the LeetHoxer threat was a little different. According to researchers, other Mirai variations too were altered including the encryption procedure, the bot program, and the command and control protocol. The unique "string and downloader" too were revealed to be of the same kind as Mirai.

Per reports, the botnet was noticed when it was found to be manipulating a vulnerability in the “telenet service” of a device. It made use of the default password to get access to the device. Once the device got infected the LeetHozer sent the information of the device to its reporter mechanism which then got to the command and control server and then finally the instructions for the Denial-of-Service attack were received.

The history of various attacks has it that Moobot has been a part of quite a lot of attacks ever since it first surfaced last year. According to researchers, several threat actors have made use of it to exploit zero-day vulnerabilities. It was discovered by the researchers while it was manipulating a zero-day vulnerability in fiber routers, reports mention. It hence is needless to say that one of the major attack tactics of the Moobot is exploiting any zero-day flaw it could get it claws into.

There are numerous ways in which an organization can create a barricade against any such attacks. The cyber and technological security personnel could design a response plan and a contingency plan especially against DDoS attacks, the systems should be backed up at all times, and configuration could be done in a way that as soon as the network is attacked the back-up kicks in. Also, researchers suggest that Artificial Intelligence could prove to be a very lucrative solution for such problems.