The threat actor behind the Fodcha distributed denial-of-service (DDoS) botnet has resurfaced with new capabilities, researchers reveal.
This includes changes to its communication protocol and the ability to extort cryptocurrency payments in exchange for stopping the DDoS attack against a target, Qihoo 360’s Network Security Research Lab said in a report published last week.
Fodcha first came to light earlier this April, with the malware propagating through known vulnerabilities in Android and IoT devices as well as weak Telnet or SSH passwords.
The cybersecurity company said that Fodcha has evolved into a large-scale botnet with over 60,000 active nodes and 40 command-and-control (C2) domains that can “easily generate more than 1 Tbps traffic.”
Peak activity is said to have occurred on October 11, 2022, when the malware targeted 1,396 devices in a single day.
The top countries singled out by the botnet since late June 2022 comprises China, the U.S., Singapore, Japan, Russia, Germany, France, the U.K., Canada, and the Netherlands.
Some of the prominent targets range from healthcare organizations and law enforcement agencies to a well-known cloud service provider that was assaulted with traffic exceeding 1 Tbps.
Fodcha’s evolution has also been accompanied by new stealth features that encrypt communications with the C2 server and embed ransom demands, making it a more potent threat.
“Fodcha reuses a lot of Mirai’s attack code, and supports a total of 17 attack methods,” the cybersecurity company noted.
The findings come as new research from Lumen Black Lotus Labs pointed out the growing abuse of the Connectionless Lightweight Directory Access Protocol (CLDAP) to magnify the scale of DDoS attacks.
To that end, as many as 12,142 open CLDAP reflectors have been identified, most of which are distributed in the U.S. and Brazil, and to a lesser extent in Germany, India, and Mexico.
In one instance, a CLDAP service associated with an unnamed regional retail business in North America has been observed directing “problematic amounts of traffic” towards a wide range of targets for more than nine months, emitting up to 7.8 Gbps of CLDAP traffic.
For decades cybersecurity professionals held tight to the idea that passwords needed to be changed on a regular basis. In recent years, however, organizations such as NIST and Microsoft have abandoned this longstanding best practice and are now recommending against mandatory password expiration.
The case against password expiration
Microsoft lists two main reasons why scheduled password expirations should be avoided.
Fast-acting criminals won’t be deterred by your 90-day change policy
First, the company argues that scheduled password changes do little to prevent an intruder from gaining access to a victim’s network because threat actors almost always make immediate use of compromised passwords.
In many ways, password theft is like credit card theft. When a criminal steals a credit card number, they know that they have a very limited amount of time before the card is reported to be stolen and is deactivated. As such, they will typically use a stolen card immediately. Password theft works the same way in that threat actors are anxious to exploit stolen credentials before compromised accounts are deactivated or passwords are changed.
End-users are tired of the needless change of a perfectly good password
The other reason that Microsoft cites in their recommendation against scheduled password expirations is that when users are forced to periodically change their passwords, they are much more inclined to use passwords that are both insecure and predictable.
This idea is based on a 2009 study by the University of North Carolina at Chapel Hill. Since most networks are configured to lock accounts after a small number of incorrect password guesses, researchers wanted to determine if it was possible to create an algorithm that could correctly guess passwords in five or fewer guesses, using one of a user’s previous passwords as a starting point.
The study found that when users are forced to periodically change their passwords, they often resort to using transformations rather than using an entirely new password. These transformations might involve replacing a character with a symbol (for example, using a dollar sign instead of the letter S) or incrementing a number to the end of the password.
By examining thousands of password histories, researchers were able to determine the types of transformations that users most often resorted to using. They then used this information to create an algorithm that has a high probability of being able to guess a user’s current password based on a previous password in five guesses or less.
From Microsoft’s perspective it is far better for a user to create a strong but unchanging password than to simply create a password that barely adheres to the organization’s minimal password requirements and then make small changes to that password each time that the organization requires the password to be changed.
What About Other Password Security Guidelines?
Although NIST and Microsoft don’t recommend mandatory scheduled password changes, not everyone is convinced. The payment card industry for example, requires any organization that accepts credit card payments to comply with PCI DSS standards.
PCI DSS 4.0, which goes into effect when PCI DSS version 3.2.1 is retired in 2024, still requires scheduled password changes. The 4.0 version of the PCI DSS standards require organizations to use passwords that are at least 12 characters in length (with some exceptions) and that passwords be changed every 90 days.
The best of both worlds
The fact that Microsoft and NIST recommend against mandatory password expirations while other industry standards such as PCI still require them clearly indicates that there is no clear-cut answer to whether forced password changes are a good thing. But what if there were an in between option?
Length-based password aging to the rescue
Specops Password Policy supports length-based password aging, which may be the happy medium that organizations are looking for. The basic idea behind this feature is that an organization can make it so that users who create strong passwords are rewarded with less frequent password changes.
On the surface, it might initially seem as though length-based password aging does not entirely solve the problem. After all, even a user who creates a super strong password is still going to be required to change that password at some point and will presumably resort to using password transformations rather than creating an entirely new password. However, length-based password aging can be used in conjunction with the Specops’ dynamic feedback feature, which collectively solves the password transformation problem.
End ambiguity with dynamic feedback at password change
Specops dynamic password feedback feature guides the user through the password reset process, showing them exactly what is required in order to satisfy the organization’s password requirements. This gives the organization an opportunity to create a policy that prevents the use of common password transformations.
If for example, a user’s original password was MyP@$$w0rd1, then then a password policy could prevent the user from changing the password to something like MyP@$$w0rd123, MyP@$$w0rd2, or MyPa$$word1. Because the policy blocks the user from using common transformation patterns, the user is forced to adopt a completely new, and secure password.
An example of dynamic feedback at password change for an end-user with Specops Password Policy
Additionally, the dynamic feedback feature guides the user through this entire process and shows the user exactly what is required thereby helping to eliminate ambiguity and its resulting user frustration.
The goal here is to combine a strong password policy with an end-user reward system, keeping your stronger password for longer, and adding in a deterrent of minimal password change all without additional onus on the IT team. After all, if password feedback exists at password change you can cut down on all those helpdesk calls asking for help.
Tesla reportedly caught an employee engaging in “malicious sabotage” at its Fremont factory, according to an internal email to employees.
Al Prescott, Tesla’s vice president of legal and acting general counsel, wrote in an email to Fremont factory employees obtained by Bloomberg:
“Two weeks ago, our IT and InfoSec teams determined than [sic] an employee had maliciously sabotaged a part of the Factory. Their quick actions prevented further damage and production was running smoothly again a few hours later.
He didn’t elaborate on what form the “sabotage attempt” took, but he said that the employee was terminated.
Bloomberg reported:
“The employee, who was not named, allegedly sought to “cover up his tracks,” blame a co-worker and destroy a company computer, the email said. “Ultimately, after being shown the irrefutable evidence, the employee confessed. As a result, we terminated employment.”
Prescott added in the email to employees:
“We place tremendous trust in our employees and value everyone’s contribution. However, whatever the personal motivations of the attacker were, these are crimes, violations of our code of conduct, and are unfair to other employees,”
In that case, a Tesla employee was actually essential in preventing the sabotage to take place.
Electrek’s Take
I’d like to know what this is about.
In the case in Nevada earlier this year, it clearly was a ransomware attempt.
Was it the same thing in Fremont? Someone got tempted by the $1 million offer or is it something else entirely?
We know that Tesla has previously stretched the term “sabotage” with employees doing things they shouldn’t do before.
If it’s serious like the attempt in Nevada in August, the employee will not just be fired, but there will also be charges against the person — unlike the case against Martin Tripp that Tesla also called sabotage.
We will have to wait and see I guess. If you have more information about it, please feel free to reach out via F[email protected], via Wickr: Fredev, or through my social media: Twitter and Instagram.
FTC: We use income earning auto affiliate links.More.
The MITRE Engenuity ATT&CK evaluations of enterprise endpoint security products provide so much detail that vendors use the results, based on the well-known MITRE ATT&CK framework, to pinpoint the weaknesses in their own offerings. Cisco’s experience with the 2022 Engenuity evaluations provides an example.
How the MITRE Engenuity ATT&CK evaluations work
Traditional antivirus evaluations merely tell you whether a particular exploit is blocked or neutralized by the antivirus product being tested.
MITRE’s yearly Engenuity ATT&CK evaluations of endpoint security products, or Evals for short, go into much more detail. They use the MITRE ATT&CK framework to examine every link of a well-known attack kill chain step-by-step, from initial access to final goal.
The Evals results can tell you, for example, whether a particular endpoint security product succeeded in blocking privilege escalation or failed to block password harvesting. Highly successful threat actors such as those emulated by the Engenuity tests use attacks involving dozens of steps, and the Evals results track the outcome of each step.
Because the results and methodologies of the evaluations are freely posted on the MITRE website, organizations that are considering new endpoint security products and are also familiar with the MITRE ATT&CK framework can pore over the results to see how well specific offerings did, and which might be the best fit for their individual security postures.
Security vendors also go over the results of the Engenuity Evals to see where their products fall short — and how they can be improved for the next round. Cisco’s own experience shows how the MITRE Engenuity ATT&CK Evals can raise the bar for all makers of endpoint security products.
How Cisco fared in the most recent MITRE Engenuity evaluations
Cisco’s Endpoint Security Advantage was one of 30 different products tested in the 2022 round of Engenuity Evals, alongside offerings from Bitdefender, CrowdStrike, FireEye, McAfee, Microsoft, Palo Alto Networks, Rapid 7 and Symantec.
Within the test environment of a Microsoft Azure cloud instance, each endpoint security offering in the most recent round of evaluations was pitted against the most common attack scenarios of two very well-known adversaries. First up was Wizard Spider, a Russian-speaking cybercrime group known to deploy infamous malware such as Conti, Emotet, Ryuk and Trickbot against organizations.
The second simulated adversary was Sandworm, aka Black Energy, a Russian state-sponsored group that first came to light attacking the Ukrainian energy sector in 2014. Sandworm is best known for the NotPetya wiper malware that spread around the world in June 2017 — and indeed, the end goal of the Sandworm simulation in the Engenuity Evals was the deployment of NotPetya.
Cisco’s 2022 MITRE Engenuity results were good. Cisco Secure Endpoint Advantage detected Wizard Spider activity in 10 out of 10 steps, and Sandworm activity in 9 out 9 steps, for an overall 100% detection rate.
A third-party overview of the 2022 MITRE Engenuity ATT&CK results found that some other security products had detection rates as low as 57%. Prevention rates varied from nearly 90% to less than 4%, and eight of the 30 vendors opted out of the prevention scores.
Yet Cisco’s results were not perfect. Its prevention rate was only 78% due to two noteworthy compromises:
First, the Wizard Spider simulation managed to dump the Active Directory database in the fourth segment of its attack against Cisco Secure Endpoint Advantage. However, because each independent segment in the simulated attacks assumes successful compromise of previous segments, it’s likely that a real-world attack would have been stopped earlier. Cisco blocked the Emotet initial access that made up the first part of the first Wizard Spider segment.
A second, more serious compromise took place in the first segment of the simulated Sandworm attack. Cisco failed to block an attacker using stolen credentials from installing command-and-control malware and gaining persistence on a Linux server. That’s game over, right away, even though Cisco did very well defending both Linux and Windows systems against the rest of the Sandworm attack.
“There could have been places where Wizard Spider could have been blocked before it even got in,” added Adam Tomeo, senior product marketing manager for Cisco Secure Endpoint. “Because this is an email compromise, Cisco Secure Email might have picked it up as well before it even had a chance to come in.”
Lessons learned and planned improvements
For Shyue Hong Chuang, product manager at Cisco Secure Endpoint, this was a teachable moment. He vowed to use the latest Engenuity results to bring Cisco’s defenses for Linux up to par with its Windows defenses.
“We’re going to increase our ability to mitigate living-off-the-land abuse by introducing more advanced behavioral protection on the Linux platform,” Chuang said. “It’s something we have seen extensively in the Windows world [and] we’re now going to come around and double down to bring that technology into the Linux platform as well.”
Indeed, Chuang said Cisco has already implemented the lessons learned from the 2021 MITRE Engenuity ATT&CK Evals, in which Cisco’s and 28 other vendors’ endpoint security products faced off against simulated Carbanak and Fin7 cybercriminal attacks.
He cited a subsequent threefold improvement in Cisco Secure Endpoint’s ability to deliver analytic detections across kill chains, which Chuang chalked up to improved MITRE ATT&CK Tactic, Technique and Sub-technique mappings, enhancing the product’s behavioral-protection capabilities and exposing behavioral telemetry to customers.
With this success, Chuang is confident that Cisco will be able to quickly improve its Linux defenses as well.
“We already have all these detections [in Linux],” he said. “Some of these come across to us as very high confidence, but we need a mechanism to kick in to kill that process. And we’re going to build that mechanism now.”
It’s Cybersecurity Awareness Month. For a CIO, this is like the holidays, and there’s lots to celebrate and lots to do. By reading this, you’re helping me check something off my list: I want everyone in the IT and security landscape to know how these two teams can work together for a more efficient, productive and secure enterprise.
To those outside the departments, IT and security teams are often conflated. (“Don’t they both deal with technical stuff?”)
And yet, IT and security have very different roles and objectives, and those objectives are often in direct conflict with one another. At the risk of oversimplification, IT is under a lot of pressure to move quickly, adjusting and rolling out DevOps with relentless speed.
Meanwhile, security is tasked with mitigating threats to existing products and making sure new releases are as secure as possible.
Fast or secure – do you have to pick one?
IT’s focus on speed doesn’t play well with security’s focus on security.
The solution isn’t to compromise on speed or security.
The solution is to enable IT and security to work together.
As CIO at Ivanti, I have the privilege of being involved in the incredible work of the IT and security teams.
A CIO perspective has allowed me insights into how these teams can leverage each other’s skills and knowledge to be even greater than the sum of their parts. With the two skilled teams we have here at Ivanti, this is saying a lot.
How to foster collaboration between IT and security
Strategy #1: IT and security teams need a single – and shared – source of truth
That seems obvious enough, right? But you’d be shocked how many IT and security teams rely on multiple, disparate, potentially conflicting sources of truth. Conflicting sources add fuel to the fire that’s already smoldering, given conflicting objectives.
Even though both teams have different tasks, they can inform those tasks with the same data points. Automating data gathering and processing can help mitigate human error and role-based biases.
Relying on the same, single source of truth also means less rework and unnecessary replication – a critical part of helping both teams be more efficient. Ivanti Neurons for ITSM delivers a single source of truth for assets, security and events.
Strategy #2: Embrace DevSecOps
DevSecOps isn’t simply about tossing security into DevOps. It’s a fundamental shift wherein security is an integral part of the DevOps processed and integrated from the very beginning – helping to align priorities.
Embracing DevSecOps also benefits IT by ensuring security isn’t slowing development by weighing in late in the game. It also benefits security by helping to ensure that the IT team isn’t rolling out products that may have security gaps that impact the security team’s objectives.
Strategy #3: Create context
Patching is an overwhelming task for even the strongest IT team. But patching without security context is nothing more than busy work. Risk-based vulnerability management makes a massive difference in threat detection and remediation, ensuring that teams are focused on the right threats at the right time.
Even better, automated risk-based intelligence creates context without creating more work for your team. And when risk-based intelligence solutions can integrate with other security and IT management tools, all key stakeholders get visibility to the same context and information so they can attack the problem together.
Strategy #4: Become customer zero
Have you prioritized security at the expense of access and usability? Have you prioritized features over security?
At Ivanti, we embrace the concept of “Customer Zero” we make ourselves the first customer for any solution before we release that solution publicly. Being customer zero can help you understand any IT and security solutions with significantly greater depth.
Adopt solutions and embrace real-world usage and feedback before you finalize any DevSecOps effort. It’s one thing to assume how a solution will affect IT, security and other teams in your enterprise – it’s another thing to know the impact and hear feedback directly from stakeholders.
The bottom line
Rather than conflict, IT and security can elevate each other. Both teams just need the right support and strategies in place.
Here’s to creating a more efficient, secure enterprise – together. Learn more about how the Ivanti Neurons hyperautomation platform can help.
