••• All important news related to new attacks and see the solutions we can offer you •••
MuddyWater Offensive Attack Against Israel
MuddyWater keeps their offensive behavior and continue to create campaigns against israeli organizations.
The MuddyWater attacks are primarily against Middle Eastern nations. However, we have also observed attacks against surrounding nations and beyond, including targets in India and the USA. MuddyWater attacks are characterized by the use of a slowly evolving PowerShell-based first stage backdoor we call “POWERSTATS”. Despite broad scrutiny and reports on MuddyWater attacks, the activity continues with only incremental changes to the tools and techniques.
Do you want to make sure your organization is hardened against Muddywater? Ask for a test with Cymulate Breach and Attack Simulation. With this solution you can fully simulate and mimic the attackers behaviour!
Security as Code: How Repeatable Policy-Driven Deployment Improves SecurityRead the original article here
Security as Code: How Repeatable Policy-Driven ... (darkreading.com)
The adoption of infrastructure as code (IaC) practices to help automate and accelerate IT operations has really taken hold in recent years — even more so during the pandemic.
With IaC, organizations are moving away from a model where humans are required to make manual changes in order to configure and deploy application infrastructure, both on-premises and more often than not, in the cloud. IaC offers the promise of automation and repeatable predictable patterns for software infrastructure deployment. There are multiple popular models and services used today for enabling an IaC approach, including Terraform, Chef, Puppet, Ansible, SaltStack, and AWS CloudFormations.
While the approach has many benefits, traditional security approaches typically slow down the software development life cycle and can evaporate the benefits of using IaC. That's why there is a real need for organizations to take a "security as code" (SaC) approach to fully recognize the benefits of automation that composable, repeatable, and fully auditable infrastructure can provide.
IaC Requires A New Security Approach
Simply put, securing automation code is critical because in many cases it literally runs our businesses. IaC systems are automatically deploying resources and applications. A vulnerability or a misconfiguration in an IaC workflow could have a cascading impact, across multiple workloads and deployments that could enable a potential attacker to cause a lot of damage. IaC is very powerful, so when mistakes happen, they happen fast, and exponentially.
One of the challenges with securing automated workflows is there can often be multiple paths into a system or service for executing an action. There could also well be multiple people from different parts of the organization that have access to the various entry points for IaC. Adding further complexity is that some organizations might not be effectively communicating about objectives and required changes across a distributed organization.
Core Security Principles
A primary foundation for securing infrastructure created and managed by IAC templates is by first establishing a source of truth for configuration. There needs to be a codified version of configuration, usually in a Git software repository, that defines the desired state of configuration. It's an approach that some refer to as GitOps, which helps to enable IaC. With a defined source of truth, it's time to implement access, audit, and review processes.
- Access control. With a defined source of truth for configuration, secure controls can and should be applied. There needs to be access control that strictly defined who can access and make changes to the configuration code
- Auditing and compliance. Controlling access is only the first part of security IaC. All changes need to be audited and monitored for compliance with corporate policy and regulatory compliance frameworks.
- Review. Even with auditing and access controls, changes that might not be ideal can still slip through the cracks. That's why it's imperative to also actively have a change management and review process to further validate the state of IaC configuration and any changes.
Define a Single, Secure Path to Production
To fully secure IaC, there also must be a well-defined single path to production, so that all stakeholders in the organization, including developers, operations, and security are involved.
Defining the path to production is often about breaking down silos within the company and focusing on cross-team collaboration. More often than not in the past, developers have viewed security as a blocker and not as an enabler. The security-as-code approach can help to change that mindset by working with developers in a language they understand: code.
A key concept that we have seen work well is the use of guardrails, rather than gates, as part of the SaC process. Rather than implementing a gate, where code cannot pass through unless it is approved by security, a guardrail keeps code within certain defined boundaries, that limits risk.
Guardrails can help developers and organizations to focus on speed, in a way without sacrificing security.
Security as Code in Practice
How does it actually work to improve security? The reality is that with continuous visibility you can ensure correctness, alert and then correct any divergence in a repeatable, auditable, secured approach.
Here's just one example where this approach can help. The issue of unsecured cloud storage buckets, often on Amazon S3, is one that is well documented and has been reported on extensively at Dark Reading and other places. The SaC model can help to effectively eliminate that risk.
By running continuous compliance assessments of cloud environments, an organization can be alerted whenever an S3 bucket has been inadvertently provisioned with public read or write access. An administrator can then go to the Git repository where the configuration code for the IaC service is defined and make the required change to eliminate the risk. After the change has been committed, it can get through the approval process, and once accepted, the IaC pipeline can execute the code to remediate the issue across all deployments. The entire process is logged and auditable as well.
6 Questions Attackers Ask Before Choosing an Asset to ExploitRead the original article here
Original Article from ThreatPost.com
In the past decade or so, we’ve seen a massive shift toward the cloud. The COVID-19 pandemic and associated pivot to remote work has only accelerated this cloud trend, forcing blue-teamers to be more agile to protect their attack surfaces. While defenders are adapting to support cloud-based environments, attacks against cloud systems have increased by 250 percent in the last year.
More assets in the cloud creates challenges for defenders, but it’s wrong to assume that this makes things easier for an adversary. Attackers don’t have time to look at every asset in depth — the number of which can run in the tens of thousands for a large enterprise. Just as there are demands on security teams, adversaries have constraints. Their time has a cost, they must operate within limited budgets and their technical capabilities have an upper boundary.
As a person who’s been hired by hundreds of CISOs to test their defenses with a red-team engagement, I’m well aware that defenders are buried in security alerts, struggling to find the right signals among the noise. These teams have dozens of security applications, checklists and a pile of processes to execute defensive strategies. Yet, a massive gap between how a blue-teamer defends and how an attacker attacks exists. Understanding the opponent — the hacker’s logic — is a solid first step to decoding the signals that matter and closing that gap. The attacker’s perspective on how an attacker evaluates assets to go after and exploit on an attack surface begins by answering six questions. And, if this logic is applied in the enterprise, its security strategy will shift, leading to more efficiencies and lower risk.
- What useful information can I see about a target from the outside? (Enumerability)
Every target in an attack surface has a story to tell, some in more detail than others. Ultimately, the more information an attacker can gather about a piece of technology used (or about a person in an organization), the more confidently they can plan a next phase of attack, so they can more confidently invade a network. The unraveling of details about a target describes enumerability — how finely an attacker can detail a target from the outside. For example, depending on the service and its deployment, a web-server target could report anything from no server identifier to the specific server name — “Apache” or “Apache 2.4.33.” If attackers can see the exact version of a service in use and its configuration, they can run precise exploits and attacks, maximizing chances of success and minimizing odds of detection.
- How valuable is this asset to the adversary? (Criticality)
Every step a hacker takes is effort, time, money and risk. It’s better to knock on doors that lead somewhere than to fumble at targets randomly. Some targets are just more likely to lead somewhere than others because their very purpose makes them a juicy target. Attackers assess criticality before acting, in order to focus their efforts on targets that are likely to lead them closer to their objectives. Security appliances like VPNs and firewalls, or remote-support solutions on the perimeter, are proverbial keys to the kingdom — compromising one can open a path to the network, and to credentials that would allow for greater network access. Likewise, credential stores and authentication systems can give the attacker more credentials if compromised. Attackers seek tools that provide the best positioning and access. Exposed assets that don’t protect, and won’t lead to, critical data or access are just less valuable to hackers.
- Is the asset known to be exploitable? (Weakness)
Contrary to popular belief, having a high severity CVSS ranking on the CVE list doesn’t automatically mean a target is of great interest to an attacker. There have been many “critical, wormable, world-ending, fire-and-brimstone” vulnerabilities that weren’t actually exploitable. Even more bugs are exploitable, but only in really specific circumstances. Some may be perfectly exploitable in theory, but nobody has actually done the work to do it. Attackers must consider the cost and likelihood of actually pwning an asset. If a useful proof-of-concept (POC) exists, that is a good indicator. If there’s lots of research and analysis about a specific vulnerability, exploitation might not be a question, it might just be work. Time is money, and exploits take time, so a hacker has to consider the tools available in public, the tools they can afford to build or tools they could buy (think Canvas or Zerodium). For a specific asset, in certain cases, adversaries buy previously-built exploits. This happens a lot more than many realize.
- How hospitable will this asset be if I pwn it? (Post-exploitation potential)
An attackers’ definition of a “hospitable environment” is one that makes it possible to live in and travel through, undetected. This is an asset where malware and pivoting tools work and where few defenses exist. This target is one that blue teams just cannot install any defenses on, so the attacker knows they can operate with little worry of being detected. Any technology that is sufficiently protected and monitored — like endpoints — are not hospitable. Desktop phones and VPN appliances, and other unprotected hardware devices that are physically plugged into the network and have familiar execution environments, make a great host. Many appliances are built with Linux and come with a complete userspace and familiar tools pre-installed, making them a target that has high post-exploitation potential.
- How long will it take to develop an exploit? (Research potential)
Knowing you’d like to attack a particular target, and actually having some exploit or technique to do so, aren’t the same thing. When looking at a particular target, a hacker has to assess how likely they are to succeed in developing a new exploit, and at what cost. Vulnerability research (VR) isn’t just for finding stuff to patch. Hackers do VR on targets because they want to exploit. The cost of that research, along with the cost of testing and polishing any resulting tools, is a part of assessing if a target is worth attacking. Well-documented, well researched or open-source tools that can easily be obtained and tested are easier targets. Expensive and esoteric platforms (usually hardware like VoIP systems or those absurdly expensive security appliances) call for special skills and resources to attack (even though they’re attractive because of value of data stored and level of access granted). Any barriers to entry limit adversaries’ incentives to target specific platforms, tools or services.
- Is there repeatable ROI developing an exploit? (Applicability)
One of the biggest shifts from defender mindset to hacker logic is understanding attackers’ business models. Attackers invest time, research and human capital creating exploits and building tools. They want the highest possible ROI. Your organization is most likely one of many a hacker is interested in, because your adversary wants to spread their costs over many victims at once. Attackers assess applicability to understand the potential to create and use an exploit beyond a single instance. With limited resources, attackers create exploits for widely-used technologies that create high earning potential across multiple targets. Remember when Macs were seen as unhackable? At the time, Microsoft had more market share, so exploiting Windows was more profitable. As Windows becomes a harder target, and Macs proliferate in the enterprise, that changes. Likewise, iOS vulnerabilities were far more expensive than Android bugs. But market forces are driving iOS vulnerabilities to be more common and less expensive (relatively).
Attackers don’t look at the severity of a bug and decide what to attack. There are many more components in planning an individual action, nevermind the long strings of actions that are part of an attack. Attackers have to manage resources while trying to achieve their objective, or indeed operate, their business. This idea that adversaries make tradeoffs too is one defenders should take to heart. In defending a business, it’s not possible to protect everything, everywhere, from all adversaries, all the time. Compromise is inevitable. The name of the game in risk management is placing defensive bets in the best ways possible to optimize a business outcome. Thinking more like an attacker can shape prioritization, and highlight the assets that are both valuable and tempting to adversaries, making it possible for businesses to decide, sometimes, that the cost of truly hardening a target just isn’t worth the benefit.
Cert2connect has various solutions to help you to look at your organization the way a hacker does.