Search This Blog

Showing posts with label SSH. Show all posts

Data From Honeypots Shows Bot Attack Trends Against RDP, SSH



Rapid7's RDP and SSH honeypots were used to collect data over nine months between September 10, 2021, and September 9, 2022. This resulted in the discovery of tens of millions of attempted connection attempts during this timeframe. Honeypots were set up over two weeks in which they captured 215,894 unique IP source addresses, 512,002 unique passwords, and both RDP and SSH honeypots. A large portion (99.997%) of the passwords can likely be found in the text file rockyou2021.txt.

The Rockyou website was hacked in 2009 as a result of a security breach. Consequently, 32 million user accounts were found in cleartext by the attackers, and they stole them. There was an exposed list containing 14,341,564 passwords that eventually turned into the original rockyou.txt list of passwords. This list was widely used in dictionary attacks and is included with Kali Linux as an aid to penetration testing.

There have been numerous password lists added to the original over the years, and updated ones are constantly being added. A result of this research is the rockyou2021.txt collection, which comprises about 8.4 billion records. It is a 92 GB text file that contains about 8.4 billion passwords. There is a pre-release version of the code on the GitHub website for free download. 

Rapid7 explains in its report titled Good Passwords for Bad Bots (PDF), "We use the RockYou set of passwords as a source of passwords that attackers could generate and try to see if there was any evolution beyond the use of a password list." 

The fact that 99.99% of the passwords used to attack Rapid7 honeypots can be found on this password list probably comes as no surprise. This is because most of the passwords used are very common. There are only 14 of the 497,848 passwords that are not included in rockyou2021, out of 497,848 passwords that are involved in the SSH attacks.

There is also an IP address included with each of these files that represent the honeypot that has been hacked. As per Rapid7, there may have been a programming error in the scanner used by the attacker, which in turn makes this situation seem more likely.

In rockyou2021, only one password among those used to attack the RDP honeypots is not included among those that were used in the attack. There was a password 'AuToLoG2019.09.25' that was the thirteenth most prevalent in the entire country. This is a bit puzzling, but the report notes there are malware samples containing the ‘AuToLoG’ string. “The samples are classified as generic trojans by most antivirus vendors but appear to have RDP credentials hardcoded into them,” adds the report.

Besides the SSH mistakes in the example above and the one AuToLog password that was used to access the honeypot, every other password that was used in those honeypot attacks can be found in rockyou2021. In general, honeypot attacks are automated opportunistic bot attacks that prey on weak signals and extract data from them.

During Rapid7's analysis of the passwords that were used, the company found that standard, well-known passwords were preferred over less common passwords. The top five RDP password attempts were: (the empty string), '123', 'password', '123qwe', and 'admin', with '' (the empty string) coming in second. According to the statistics, 123456, nproc, test, qwerty, and password were the top five SSH password attempts over the last 12 months. All of these passwords, as well as all of the others, could have been obtained from rockyou2021.

Rockyou2021 is effectively nothing more than a massive list of words. Random ASCII and mixed ASCII string strings as well as special character strings do not fall under the definition. The number of possible ASCII seven-character strings is approximately 8.4 billion, which would mean that if we added up every possible variation of ASCII seven characters, it would take around 70 trillion possibilities to find the complete set.

With the length of a password being increased, the probability that this would happen will rise dramatically. From Rapid7's analysis, the overriding conclusion is that the use of long, strong random strings like those generated by password manager applications and which are not likely to be included in dictionaries would provide a very strong defense against opportunistic bot-driven automated attacks that are carried out by hackers.

Despite their low costs, Tod Beardsley, Rapid Seven's director of research, advises that these automated attacks are not complementary to each other, but are rather low-cost. As a result, this indicates that password managers are currently not the default method of generating and storing passwords, which signifies that this needs to change. It is imperative to note that password managers have one major drawback, which is that they are not always intuitive or easy to use.

FortiGuard Labs: Evolving RapperBot IoT Malware Detected

Since June, FortiGuard Labs has been monitoring the "RapperBot" family of revolving IoT malware. Although the original Mirai source code was greatly influenced by this family, it differs from other IoT malware families in that it has the capacity to brute force credentials and connect to SSH servers rather than Telnet, which was how Mirai implemented it. 

The malware is alleged to have gathered a series of hacked SSH servers, with over 3,500 distinct IP addresses used to scan and brute-force its way into the servers. The malware is named from an encoded URL to a YouTube rap music video in an early draft.

Analysis of the malware

According to the Fortinet analysis, the majority of the malware code implements an SSH 2.0 client that can connect to and brute force any SSH server that supports Diffie-Hellmann key exchange with 768-bit or 2048-bit keys and data encryption using AES128-CTR.

RapperBot turned out to be a Mirai fork with unique features, its own command and control (C2) protocol, and unusual post-compromise for a botnet. RapperBot was created to target ARM and MIPS and has limited DDoS capabilities.

The attempt to create durability on the compromised host, which effectively allows the hacker to keep ongoing access long after the malware has been uninstalled or the unit has been restarted, serves as further proof of how Mirai has deviated from its usual behavior.

RapperBot used a self-propagation technique via a remote binary downloader, which was eliminated by the hackers in mid-July, as per Fortinet researchers who watched the bot and proceeded to sample new variants.

The recent versions in circulation at the time included a shell command that switched the victim's SSH keys for the hackers. A unique file named "/.ssh/authorized keys" is used to get access by inserting the operators' SSH public key. This enables the attacker to log in and authenticate to the server using the associated private key without providing a password.

The root user "suhelper" is added by the bot to the compromised endpoints in the most recent samples that the researchers have examined. The bot also sets up a Cron job to add the user again every hour if an administrator finds the account and deletes it.

Observations 

As per Fortinet, analysts observed no new post-compromise payloads transmitted during the monitoring time, so the virus simply lays dormant on the affected Linux systems. 

Despite the botnet abandoning self-propagation in favor of persistence, it is said that the botnet underwent substantial alterations in a short period of time, the most notable of which being the removal of DDoS attack elements from the artifacts at one point, only to be reinstated a week later.

At best, the campaign's ultimate goals are still unclear, and little more action is taken after a successful compromise. It is evident that SSH servers with pre-configured or easily guessable credentials are being gathered into a botnet for some unknown future use.

Users should set secure passwords for their devices or, turn off password authentication for SSH to protect themselves from such attacks.

Chinese Group Botnet Illegally Mine Crypto

 

Linux and cloud app vulnerabilities have been used by the 8220 Group crypto mining gang to expand their botnet to over 30,000 affected systems.

Over the course of just the previous month, SentinelOne researchers reported detecting this notable rise in the number of infected hosts. The malicious botnet, according to analysts, was only active on 2,000 servers worldwide by the middle of 2021.

The 8220 group has been operating at least since 2017. The hackers are China-based and the organization's name is derived from the port 8220 that the miner uses to connect to the C2 servers. 

Operation tactics

According to reports, the growth was spurred by the adoption of Linux, widespread vulnerabilities in cloud applications, and inadequately secured setups for services like Docker, Apache WebLogic, and Redis.

This group has used a publically available exploit in the past to breach confluence systems. Once inside, the attackers employ SSH brute force to spread out and commandeer the available computing power to operate crypto miners that point to untraceable pools.

Another improvement is the script's usage of block lists to prevent infections on particular hosts, usually, honeypots set up by security researchers.

Lastly, 8220 Gang has updated PwnRig, their proprietary crypto miner based on XMRig, an open-source Monero miner.

Microsoft researchers claim that the gang has actively upgraded its payloads and tactics over the past year. In a recent campaign, the organization targeted Linux systems running on i686 and x86 64 architectures and gained early access using RCE exploits for CVE-2022-26134 (Atlassian Confluence) CVE-2019-2725 (WebLogic) vulnerabilities.

In addition to underscoring a more intense "fight" to seize control of victim systems from rival cryptojacking-focused groups, the operations' expansion is seen as an effort to counteract the declining value of cryptocurrencies.



Safeguarding From Container Attacks Inside the Cloud


As an alternative to virtualization, containerization has become a key trend in software development. It entails encapsulating or packaging software code and all of its dependencies so it may execute consistently and uniformly across any infrastructure. Containers are self-contained units that represent whole software environments that may be transported. They include everything a program needs to run, including binaries, libraries, configuration data, and references. Docker and Amazon Elastic, as an illustration, are two of the extra well-known choices. 

Although many containers can run on the same infrastructure and use the same operating system kernel, they are isolated from such a layer and have a little interface with the actual hosting elements, for instance, a public cloud occasion. The ability to instantly spin up and down apps  for users, is one of the many advantages of running cloud-based containers. Admins may utilize orchestration to centrally manage containerized apps and services at scale, such as putting out automatic updates and isolating any malfunctioning containers.

Container adoption is at an all-time high, worldwide businesses of all sizes are eager to jump on board. According to a poll conducted by the Cloud Native Computing Foundation (CNCF), 83 percent of respondents plan to use Kubernetes in production in 2020, up from 78 percent the year before and just 58 percent in 2018. As adoption grows, cybercriminals' interest grows as well. According to a June Red Hat study, 94 percent of respondents have experienced a Kubernetes security problem in the last 12 months. 

Larry Cashdollar, an Akamai security researcher, recently set up a basic Docker container honeypot to test what type of attention it would get from the larger web's cybercriminals. The results were alarming: in just 24 hours, the honeypot was used for four different nefarious campaigns. Cashdollar had integrated SSH protocol for encryption and developed a “guessable” root password. It wouldn't stick out as an obvious honeypot on the web because it was running a typical cloud container configuration, he explained. It would instead appear to be a vulnerable cloud instance. The assaults had a variety of objectives: one campaign aimed to utilize the container as a proxy to access Twitch feeds or other services, another attempted a botnet infection, a third attempted crypto mining, and the fourth attempted a work-from-home hoax. 

"Profit is still the key motivator for cybercriminals attacking containers," as these cases demonstrate, according to Mark Nunnikhoven, a senior cloud strategist at Lacework. "CPU time and bandwidth can be rented to other criminals for buried services, or even used to directly mine cryptocurrencies. Data can be sold or ransomed at any time. In an environment where containers are frequently used, these reasons do not change." 

According to a recent Gartner study, client misconfigurations or mistakes would be the primary cause of more than 99 percent of cloud breaches by 2025. As per Trevor Morgan, product manager at comfort AG, most businesses, particularly smaller businesses, rely on default configuration options rather than more advanced and granular setup capabilities: "Simple errors or selecting default settings  that are far less safe than customized options." The problems with configuration typically go beyond the containers themselves. Last July, for example, misconfigured Argo Workflows servers were detected attacking Kubernetes clusters. 

Argo Workflows is an open-source, container-native workflow engine for coordinating parallel activities on Kubernetes to reduce processing time for compute-intensive tasks such as machine learning and large data processing. 

According to an examination by Intezer, malware operators were using publicly available dashboards which did not require authentication for outside users to drop crypto miners into the cloud. Far above misconfiguration, compromised images or layers are the next most serious threat to containers, according to Nunnikhoven. "Lacework Labs has witnessed multiple instances of cybercriminals infiltrating containers, either through malware implants or pre-installed crypto mining apps," he said. "When a group deploys the pictures, the attacker has access to the victim's resources."

According to Gal Singer, an Aqua Security researcher, the flaw (CVE-2020-15157) was discovered in the container image-pulling process. Adversaries may take advantage of this by creating dedicated container images which stole the host's token when they were pulled into a project.  Similarly, a denial-of-service vulnerability in one of Kubernetes' Go libraries (CVE-2021-20291) was discovered to be exploited by storing a malicious picture in a registry. When the image was taken from the registry by an unwary user, the DoS condition was generated.

The second source of concern is vulnerabilities, both known and unknown. In 2021, several container flaws were discovered, but "Azurescape" was likely the most alarming. Within Microsoft's multitenant container-as-a-service offering, Unit 42 researchers found a chain of exploits that might allow a hostile Azure user to infect other customers' cloud instances. 

Containerized environments can provide unique issues in terms of observability and security controls, according to Nunnikhoven, but a comprehensive security approach can help. Researchers recommended that users apply a laundry list of best practices to secure their Kubernetes assets: 

  • Avoid using default settings; use secure passwords.
  • To prevent attackers from impersonating the token owner, do not send privileged service account tokens to anyone other than the API server. 
  • Enable the feature "BoundServiceAccountTokenVolume": When a pod ends, its token becomes invalid, reducing the risk of token theft.
  • Examine orchestrators for least-privilege settings to verify that CI/CD movements are authenticated, logged, and monitored. 
  • Be comprehensive: Create a unified risk picture that includes both cloud-based applications and traditional IT infrastructure. 
  • Have data-analysis software in place, as well as an automatic runbook that can react to the findings.

By Attacking Healthcare, Education, and Government Systems, FritzFrog Botnet Grew Tenfold

 

The FritzFrog botnet, which has been active for over two years, has revived with an alarming infection rate, growing tenfold in just a month of attacking healthcare, education, and government networks via an unprotected SSH server. FritzFrog, a malware developed in Golang that was discovered in August 2020, is both a worm and a botnet that targets the government, education, and finance sectors. 

The malware fully assembles and executes the malicious payload in memory, making it volatile. Furthermore, because of its unique P2P implementation, there is no central Command & Control (C&C) server giving commands to FritzFrog. It is self-sufficient and decentralised. Despite FritzFrog's harsh brute-force tactics for breaching SSH servers, it is strangely efficient at targeting a network equitably. 

Guardicore Labs has been monitoring FritzFrog with its honeypot network for some time. "We started monitoring the campaign’s activity, which rose steadily and significantly with time, reaching an overall of 13k attacks on Guardicore Global Sensors Network (GGSN). Since its first appearance, we identified 20 different versions of the Fritzfrog binary," said the company in a report published in August 2020, authored by security researcher Ophir Harpaz.

Researchers at internet security firm Akamai discovered a new version of the FritzFrog malware, which has intriguing new features such as the use of the Tor proxy chain. The new botnet variation also reveals signs of its operators planning to enhance capabilities to target WordPress servers. 

Athough the Akamai global network of sensors identified 24,000 attacks, the botnet has claimed only 1,500 victims thus far. The majority of infected hosts are in China, although affected systems can also be found in a European TV network, a Russian healthcare organisation, and other East Asian universities. The perpetrators have included a filtering list to avoid low-powered devices like Raspberry Pi boards, and the malware also includes code that lays the basis for targeting WordPress sites. 

Given that the botnet is renowned for cryptocurrency mining, this feature is an odd inclusion. However, Akamai believes that the attackers have discovered new means of monetization, such as the deployment of ransomware or data leaks. This functionality is currently dormant while it is being developed. The researchers point out that FritzFrog is always in development, with bugs being resolved on a daily basis. 

FritzFrog targets any device that exposes an SSH server, therefore administrators of data centre servers, cloud instances, and routers must be careful, according to the researchers. Some security tips from Akamai include enabling system login auditing with alerting, monitoring the authorized_hosts file on Linux, configuring an explicit allow list for SSH login, and so on.

GitHub Announced Security Key Support for SSH Git Operations

 

When using Git over SSH, GitHub, the ubiquitous host for software creation and version control (and unfortunate victim of a relentless stream of attacks targeting the same), now supports encryption keys.

GitHub security engineer Kevin Jones said in a blog post on Monday that this is the next step in improving security and usability. These portable FIDO2 fobs are used for SSH authentication to protect Git operations and avoid the havoc that can occur when private keys are misplaced or stolen, or when malware attempts to execute requests without user permission. For instance, in 2019, the TrickBot data-stealing malware was updated to include a password grabber that could attack data from OpenSSH applications. 

These security keys, which include the YubiKey, Thetis Fido U2F Security Key, and Google Titan Security Keys, are easy to carry around in your pocket and attach to computers via USB, NFC, or Bluetooth. They can be used instead of one-time passwords generated by apps or sent via SMS. SMS SSH codes sent via text can currently be intercepted.

Strong passwords are still relevant, but because of the proliferation of data breaches and cyberattacks, they are becoming less useful as a single security mechanism, prompting the development of password managers that often check for credential leakage online, biometrics, and security keys. 

"We recognize that passwords are convenient, but they are a consistent source of account security challenges," Jones commented. "We believe passwords represent the present and past, but not the future. By removing password support for Git, as we already successfully did for our API, we will raise the baseline security hygiene for every user and organization, and for the resulting software supply chain." 

Since keys are one of the variables in multi-factor authentication (MFA), users can treat them with the same care as any other credential. You should have your security key plugged in if you're the only one that has access to it. “When using SSH with a security key, none of the sensitive information ever leaves the physical security key device,” Jones added. “If you’re the only person with physical access to your security key, it’s safe to leave plugged in at all times.” 

When you use a security key, neither ransomware nor unintended private-key leakage will reveal your keys, he said: “As long as you retain access to the security key, you can be confident that it can’t be used by anyone else for any other purpose.”

GitHub Informed Clients of “Potentially Serious” Security Bug

 

GitHub on Monday informed clients that it had found what it described as an “extremely rare, but potentially serious” security bug identified with how some authenticated sessions were handled. On 8th March GitHub signed out all clients that were signed in before March 8th. The precautionary measure was taken seven days after the organization had gotten an underlying report of dubious conduct, from an external party. 

The Microsoft-owned software development platform said the bug was found on March 2 and an underlying patch was carried out on March 5. A subsequent fix was delivered on March 8 and on the evening of that very day the organization chose to invalidate all authenticated sessions to completely eliminate the possibility of exploitation. On Friday, the GitHub team has remediated the security flaw and kept on analyzing the situation over the weekend. The vulnerability being referred to, could be misused in extremely rare circumstances, when a rare condition would happen during the backend request handling process, permitting the session cookie of a logged-in GitHub client to be sent to the software of another client, giving the latter access to the former user’s account.

“It is important to note that this issue was not the result of compromised account passwords, SSH keys, or personal access tokens (PATs) and there is no evidence to suggest that this was the result of a compromise of any other GitHub systems,” says Mike Hanley, GitHub’s recently appointed chief security officer. “Instead, this issue was due to the rare and isolated improper handling of authenticated sessions. Further, this issue could not be intentionally triggered or directed by a malicious user.” 

The organization declared that the bug existed on GitHub.com for less than two weeks and it doesn't resemble some other GitHub.com assets or products were impacted as a result of this bug. "We believe that this session misrouting occurred in less than 0.001% of authenticated sessions on GitHub.com. For the very small population of accounts that we know to be affected by this issue, we’ve reached out with additional information and guidance,” continues Hanley in the announcement. 

The organization is still analyzing if any project repositories or source code were messed with because of this vulnerability as this kind of authentication vulnerabilities could pave the way for software supply-chain attacks.

Secure your Home Server from being used as a Hacking Server by Crooks


SSH also referred to as Secure Shell, is a cryptographic network protocol which secures remote login from one computer to another. It is employed by almost all the Linux sysadmins and although Windows users are more acquainted with Remote Desktop Protocol (RDP), many of Window sysadmins also use SSH instead of RDP, the reason being its Raw power.

RDP provides full graphical remote control of a Windows computer to its users along with access to the regular Windows desktop through keyboard and mouse, whereas SSH, which is comparatively more genric, allows user to run almost every program remotely which further lets him administer the system automatically from a distance through pre-written scripts or by entering commands live, it also allows user to do both simultaneously.

Resultantly, cybercriminals who somehow can get access to a user's SSH password can also access his system, if not the entire network.

Network tunneling is another feature provided by SSH, wherein, users build an encrypted network connection between multiple computers, they start from one computer to another and extends that connection to a third system to carry out the online work.

SSH server also acts as a special-purpose VPN or encrypting proxy when it allows users to redirect network traffic when they are on the go.

Therefore, criminals who have access to any user's SSH password can use his server as the basis for his future attacks and the victims would be blaming the owner of the server.

Now, unfortunately, people have an SSH server at their home even if they don't realize it as home routers have a pre-configured SSH server which is placed for administrative reasons.

While hacking, cybercriminals do not differentiate between the SSH servers manages by users themselves and those managed by their ISP's, they go on exploiting regardless, as these servers can potentially allow them to breach data and make a profit via reselling it.

Users are advised to take the time to understand and get familiar with their router's configuration settings, in the cases where it is not managed by ISP. Furthermore, turn off all the features you don't require and also the ones you are not certain about. Lastly, ensure that you are using the latest version.