Canon Medical Informatics Vitrea Vision 7.7.76.1 does not adequately enforce access controls. An authenticated user is able to gain unauthorized access to imaging records by tampering with the vitrea-view/studies/search patientId parameter.

CVE-2022-38765: Canon Medical Software Security Updates

Following a year of increasingly disruptive attacks, advanced persistent threat groups will likely only become emboldened in 2023, security experts say.

In November, Ukraine's president revealed that the country's IT defenses fended off more than 1,300 Russian cyberattacks, including attacks on satellite communications infrastructure.

The onslaught of cyberattacks highlights one of the shifts in advanced persistent threat (APT) attacks seen in the past year: In 2022, geopolitical tensions ratcheted up, and along with them, cyber operations became the go-to strategy for national governments. While Russia and other nations have used cyberattacks to support military actions in the past, the ongoing war represents the most sustained cyber operation to date and one that will undoubtedly continue in the coming year, experts say.

Military conflict will join cybercrime as a driving force behind APT groups in the coming year, John Lambert, corporate vice president and distinguished engineer at Microsoft's Threat Intelligence Center, stated in the company's Digital Defense Report 2022 released last month.

"The conflict in Ukraine has provided an all-too-poignant example of how cyberattacks evolve to impact the world in parallel with military conflict on the ground," he said. "Power systems, telecommunication systems, media, and other critical infrastructure all became targets of both physical attacks and cyberattacks."

While the increased use of APT attacks by Russia is the most visible change that occurred in the past year, APTs are evolving. More are moving onto critical infrastructure, adopting dual-use tools and living-off-the-land techniques, and pinpointing the software supply chain to gain access to targeted companies.

Cybercriminals are using increasingly sophisticated tools, but APT techniques are typically attributed to nation-state operations, meaning that companies need to become more aware of the techniques used by advanced actors and how they may be motivated by geopolitical concerns, says Adam Meyers, senior vice president of intelligence for cybersecurity services firm CrowdStrike.

"You don't have one uniform threat — it changes by business vertical and geo-location," he says. "You — and this has been our mantra for many years — don't have a malware problem, you have an adversary problem, and if you think about who those adversaries are, what they are after, and how they operate, then you will be in a much better position to defend against them."

**Critical Infrastructure, Satellites Increasingly Targeted**

In 2021, the attack on oil-and-gas distributor Colonial Pipeline highlighted the impact that cybersecurity weakness could have on the US economy. Similarly, this year's attack on the Viasat satellite communication system — likely by Russia — showed that APT threat actors have continued to focus on disrupting critical infrastructure through cyberattacks. The trend has gained momentum over the past year, with Microsoft warning that the number of nation-state notifications (NSNs) the company issued as alerts to customers more than doubled, with 40% of the attacks targeting critical infrastructure, compared to 20% in the prior year.

Critical infrastructure is not just a target of nation-state actors. Cybercriminals focused on ransomware are also targeting critical infrastructure companies, as well as pursuing a hack-and-leak strategy, Kaspersky stated in its recently published APT predictions.

"We believe that in 2023 we will see a record number of disruptive and destructive cyberattacks, affecting government, industry, and critical civilian infrastructure — perhaps energy grids or public broadcasting, for instance," says David Emm, principal security researcher at Kaspersky. "This year, it became clear just how vulnerable physical infrastructure can be, so it's possible we might see targeting of underwater cables and fibre distribution hubs."

**Not Just Cobalt Strike**

Cobalt Strike has become a popular tool among APT groups, because it provides attackers — and when used for its legitimate purposes, red teams and penetration testers — post-exploitation capabilities, covert communications channels, and the ability to collaborate. The red-team tool has "crop\[ped\] up in a myriad of campaigns from state-sponsored APTs to politically motivated threat groups," says Leandro Velasco, a security researcher with cybersecurity firm Trellix.

Yet, as defenders have increasingly focused on detecting both Cobalt Strike and the popular Metasploit Framework, threat actors have moved toward alternatives, including the commercial attack simulation tool Brute Ratel C4 and the open source tool Sliver.

"Brute Ratel C4 ... is especially dangerous since it has been designed to avoid detection by antivirus and EDR protection," Kaspersky's Emm says. Other up-and-coming tools include Manjusaka, which has implants written in Rust for both Windows and Linux, and Ninja, a remote exploitation and control package for post exploitation, he says.

**Identity Under Attack**

Following the coronavirus pandemic, remote work — and the cloud services to support such work — have increased in importance, leading attackers to target those services with identity attacks. Microsoft, for example, saw 921 attacks every second, a 74% increase in volume over the past year, the company stated in its report.

In fact, identity has become a critical component to securing the infrastructure and enterprise, while at the same time becoming a major target of APT groups. Every breach and compromise investigated by CrowdStrike in the past year has had an identity component, CrowdStrike's Meyers says.

"We used to say trust, but verify, but the new mantra is verify and then trust," he says. "These attackers have started targeting that soft underbelly of identity ... that is a complex part of the system."

**IT Supply Chains Under Attack**

The attack on SolarWinds and the widely exploited vulnerability in Log4J2 demonstrated the opportunities that vulnerabilities in the software supply offer to attackers, and companies should expect APT groups to create their own vulnerabilities through attacks on the software supply chain.

While there has been no major event yet, attackers have targeted Python ecosystems with dependency confusion attacks against open source repositories and phishing attacks targeting Python developers. Overall, the number of attacks targeting developers and companies increased by more than 650% over the past year.

In addition, APT actors are finding the weak points in vendor and supplier relationships and exploiting them. In January, for example, the Iran-linked DEV-0198 group compromised an Israeli cloud provider by using a compromised credential from a third-party logistics company, according to Microsoft's report.

"This past year of activity demonstrates that threat actors ... are getting to know the landscape of an organization's trusted relationships better than the organizations themselves," the report stated. "This increased threat emphasizes the need for organizations to understand and harden the borders and entry points of their digital estates."

To harden their defenses against APT groups and advanced attacks, companies should regularly verify their cybersecurity hygiene, develop and deploy incident response strategies, and integrate actionable threat intelligence feeds into their processes, says Trellix's Velasco. To make identity attacks more difficult, multifactor authentication should be routine, he says.

"In 2023, simple security planning is not enough to deter or prevent attackers," Velasco says. "System defenders need to implement a more proactive defensive approach."

Where Advanced Cyberttackers Are Heading Next: Disruptive Hits, New Tech

Though there have been fewer than expected publicly reported attacks involving the vulnerability, nearly three-quarters of organizations remain exposed to it.

The Log4j vulnerability continues to present a major threat to enterprise organizations one year after the Apache Software Foundation disclosed it last November — even though the number of publicly disclosed attacks targeting the flaw itself has been less than many might have initially expected.

A high percentage of systems still remain unpatched against the flaw, and organizations face challenges in finding and remediating the issue and then preventing the flaw from being reintroduced into the environment, security researchers say.

"The fact that Log4j is used in \[nearly\] 64% of Java applications and only 50% of those have updated to a fully fixed version means attackers will continue to target it," says David Lindner, CISO at Contrast Security. "At least for now, attackers continue to have a field day in finding paths to exploit through Log4j."

**Multiple Attacks But Fewer Than Expected**

The Log4j flaw (CVE-2021-44228), commonly referred to as Log4Shell, exists in Log4j's Java Naming and Directory Interface (JNDI) function for data storage and retrieval. It gives remote attackers a trivially easy way to take control of vulnerable systems — a problem given that Log4J is used in virtually every Java application environment. Security researchers consider it as one of the most significant vulnerabilities in recent years because of its prevalence and the relative ease with which attackers can exploit it.

Over the past year, there have been numerous reports about threat actors targeting the flaw as a way to gain initial access into a target network. Many of these attacks have involved nation-state-backed advanced persistent threat (APT) groups from China, North Korea, Iran, and other countries. In November, for instance, the US Cybersecurity and Infrastructure Security Agency (CISA) warned about an Iran-government-backed APT group exploiting the Log4j vulnerability in an unpatched VMware Horizon server to deploy cryptomining software and credential harvesters on a federal network.

The warning was similar to one from Fortinet in March about Chinese threat actor Deep Panda using the identical vector to deploy a backdoor on target systems and another from Ahn Labs about North Korea's Lazarus Group distributing its own backdoor the same way. Others such as Microsoft have also reported observing state actors such as Iran's Phosphorous group and China's Hafnium threat actor using Log4 to drop reverse shells on infected systems.

Despite such reports — and several others about financially motivated cybercrime groups targeting Log4j — the actual number of publicly reported compromises involving Log4 has remained comparatively low, especially when compared to incidents involving Exchange Server vulnerabilities like ProxyLogon and ProxyShell. Bob Huber, chief security officer at Tenable, says the scale and scope of reported attacks have been surprisingly lower than expected, considering the simplicity of the vulnerability and the attack path. "Only recently have we seen some significant evidence of targeting, as noted by recent nation state activity from CISA," Huber says.

**Undiminished Threat**

However, that does not mean the threat from Log4j has diminished over the past year, security researchers note.

For one thing, a large percentage of organizations remain as vulnerable to the threat as they were a year ago. An analysis of telemetry related to the bug that Tenable recently conducted showed 72% of organizations were vulnerable to Log4j, as of Oct. 1. Tenable found that 28% of organizations globally have fully remediated against the bug. But Tenable found that organizations which had remediated their systems often encountered Log4j again and again as they added new assets to their environments.

In many instances — 29%, in fact — servers, Web applications, containers, and other assets became vulnerable to Log4j soon after initial remediation.

"Assuming organizations build the fix into the left side of the equation — during the build pipeline for software — rates of reintroduction should diminish," Huber says. "Much of the rate of reintroduction and change depends greatly on an organization's software release cycle."

Also, despite almost ubiquitous awareness of the flaw within the cybersecurity community, vulnerable versions of Log4j remain vexingly hard to find at many organizations because of how applications use it. Some applications might use the open source logging component as a direct dependency in their applications, and in other instances an application might use Log4j as a transitive dependency — or a dependency of another dependency, says Brian Fox, CTO at Sonatype.

"Since transitive dependencies are introduced from your direct dependency choices, they may not always be known or directly visible to your developers," Fox says.

In many cases, when the Apache Foundation first disclosed Log4Shell, companies had to send out thousands of internal emails, collect results in spreadsheets, and recursively scan file systems, Fox says. "This cost companies valuable time and resources to patch the component and prolonged the magnitude of the vulnerability's malicious effect," he says.

Data from the Maven Central Java repository that Sonatype maintains shows that 35% of Log4 downloads currently continue to be of vulnerable versions of the software. "Many companies are still trying to build their software inventory before they can even begin a response and are unaware of the implications of transitive dependencies," Fox says.

Because of all of the issues, the US Department of Homeland Security review board earlier this year concluded that Log4 is an endemic security risk that organizations will need to contend with for years. Members of the board assessed that vulnerable instances of Log4j will remain in systems for many years to come and put organizations at risk of attack for the foreseeable future.

**The One Positive Outcome**

Security researchers tracking the bug say that the positive fallout from Log4j is the heightened attention it has drawn to practices such as software composition analysis and software bill of materials (SBOM). The challenges that organizations have faced just determining whether they are vulnerable or where the vulnerability might exist in their environment has fostered a better understanding of the need for visibility into all the components in their codebase — especially those from open source and third-party sources.

"The investigation into the Log4J issue has reaffirmed the need for better software supply chain attestation in addition to SBOMs that keep up with the speed of DevOps," says Matthew Rose, CISO at ReversingLabs. "Application security and architecture teams have realized that just looking for risk in parts of the application like source code, APIs, or open source packages is not enough. They now realize that a complete understanding of the application's architecture is just as important as finding SQLI or cross-site scripting bugs (XSS)," he says.

One Year After Log4Shell, Most Firms Are Still Exposed to Attack

super-xray is a web vulnerability scanning tool. Versions prior to 0.7 assumed trusted input for the program config which is stored in a yaml file. An attacker with local access to the file could exploit this and compromise the program. This issue has been addressed in commit `4d0d5966` and will be included in future releases. Users are advised to upgrade. There are no known workarounds for this issue.

@@ -12,7 +12,9 @@ import com.intellij.uiDesigner.core.Spacer; import org.apache.log4j.LogManager; import org.apache.log4j.Logger; import org.yaml.snakeyaml.LoaderOptions; import org.yaml.snakeyaml.Yaml; import org.yaml.snakeyaml.constructor.SafeConstructor;  
import javax.swing.\*; import javax.swing.border.TitledBorder; @@ -224,7 +226,7 @@ public void reloadConfig(boolean init, boolean reset) { } configTemplate = configStr;  
Yaml yaml = new Yaml(); Yaml yaml = new Yaml(new SafeConstructor(new LoaderOptions())); configObj = yaml.load(configStr);  
try { @@ -684,7 +686,7 @@ public void initPluginSave() { }  
public void refreshConfig() { Yaml yaml = new Yaml(); Yaml yaml = new Yaml(new SafeConstructor(new LoaderOptions())); StringWriter writer = new StringWriter(); yaml.dump(configObj, writer); configStr = writer.toString();

CVE-2022-41958: yaml rce · 4ra1n/super-xray@4d0d596

By Waqas
The attack, according to authorities, was launched on the Federal Civilian Executive Branch (FCEB).
This is a post from HackRead.com Read the original post: Log4Shell – Iranian Hackers Accessed Domain Controller of US Federal Network

In December last year, it was reported that Iranian and Chinese hackers were exploiting the Log4Shell vulnerability in the wild. Now, according to the US CISA (Cyber security infrastructure and security Agency), an advanced persistent threat (APT) group sponsored by the Iranian government compromised the network of a U.S. federal agency.

The attack, according to authorities, was launched on the Federal Civilian Executive Branch (FCEB).

**Cyberattack Details**

CISA revealed that the hackers used the Log4Shell vulnerability, tracked as CVE-2021-44228, in the unpatched VMware Horizon server to compromise the network and gain control of the organization’s domain controller (DC). Once they successfully invaded the system, the hackers deployed XMRig crypto mining software to steal credentials and mine for crypto.

For your information, Log4Shell is a zero-day vulnerability in a Java logging framework called Log4j that causes arbitrary code execution and impacts VMware Horizon and an extensive array of products.

**CISA’s Analysis**

As per CISA, their researchers conducted a routine investigation in April 2022 and identified suspicious APT activities on the FCEB network using the EINSTEIN intrusion detection system used by the agency.

They discovered bi-directional traffic passing through the network and an already found malicious I.P. address linked with Log4Shell vulnerability exploitation in VMware Horizon servers.

CISA further noted that an HTTPS activity was launched from I.P. address 51.89.18164 to VMware’s server. Further probe revealed that the I.P. address was associated with Lightweight Directory Access Protocol (LDAP) server operated by attackers to deploy Log4Shell.

**Who are the Attackers?**

In a joint advisory from CISA, the Department of Homeland Security, and the FBI, it was revealed that the attack was launched in February 2022. The attackers moved laterally to DC, stole credentials, and implanted Ngrok reverse proxies on multiple hosts to retain persistence. U.S. security officials responded in June to clean the network.

Reportedly, the hackers were identified as Nemesis Kitten, and they launched the attack with backing from the Iranian government. Nemesis Kitten is an extension of the Phosphorus Iranian malware group, and they regularly utilize well-known, highly exploitable vulnerabilities to facilitate ransomware attacks against organizations.

CISA warned that organizations still using the unpatched server versions should be concerned as they would eventually be compromised.

1.  Dirty Pipe Linux Vulnerability Overwrites Data
2.  Watch Out: Microsoft Office 0-Day Vulnerability Follina
3.  OpenSSL Released Patch for High-Severity Vulnerability
4.  Flaw in GPS Tracker Lets Hackers Remotely Control Vehicles
5.  Critical Amazon Ring Flaw Could Expose Camera Recordings

I am a UK-based cybersecurity journalist with a passion for covering the latest happenings in cyber security and tech world. I am also into gaming, reading and investigative journalism

Log4Shell – Iranian Hackers Accessed Domain Controller of US Federal Network

Iranian government-sponsored threat actors have been blamed for compromising a U.S. federal agency by taking advantage of the Log4Shell vulnerability in an unpatched VMware Horizon server.
The details, which were shared by the U.S. Cybersecurity and Infrastructure Security Agency (CISA), come in response to incident response efforts undertaken by the authority from mid-June through mid-July 2022

Iranian government-sponsored threat actors have been blamed for compromising a U.S. federal agency by taking advantage of the Log4Shell vulnerability in an unpatched VMware Horizon server.

The details, which were shared by the U.S. Cybersecurity and Infrastructure Security Agency (CISA), come in response to incident response efforts undertaken by the authority from mid-June through mid-July 2022.

"Cyber threat actors exploited the Log4Shell vulnerability in an unpatched VMware Horizon server, installed XMRig crypto mining software, moved laterally to the domain controller (DC), compromised credentials, and then implanted Ngrok reverse proxies on several hosts to maintain persistence," CISA noted.

LogShell, aka CVE-2021-44228, is a critical remote code execution flaw in the widely-used Apache Log4j Java-based logging library. It was addressed by the open source project maintainers in December 2021.

The latest development marks the continued abuse of the Log4j vulnerabilities in VMware Horizon servers by Iranian state-sponsored groups since the start of the year. CISA did not attribute the event to a particular hacking group.

However, a joint advisory released by Australia, Canada, the U.K., and the U.S. in September 2022 pointed fingers at Iran's Islamic Revolutionary Guard Corps (IRGC) for leveraging the shortcomings of post-exploitation activities.

The affected organization, per CISA, is believed to have been breached as early as February 2022 by weaponizing the vulnerability to add a new exclusion rule to Windows Defender that allowlisted the entire C:\\ drive.

Doing so made it possible for the adversary to download a PowerShell script without triggering any antivirus scans, which, in turn, retrieved the XMRig cryptocurrency mining software hosted on a remote server in the form of a ZIP archive file.

The initial access further afforded the actors to fetch additional files such as PsExec, Mimikatz, and Ngrok, in addition to using RDP for lateral movement and disabling Windows Defender on the endpoints.

"The threat actors also changed the password for the local administrator account on several hosts as a backup should the rogue domain administrator account get detected and terminated," CISA noted.

Also detected was an unsuccessful attempt at dumping the Local Security Authority Subsystem Service (LSASS) process using the Windows Task Manager, which was blocked by the antivirus solution deployed in the IT environment.

Microsoft, in a report last month, revealed that cybercriminals are targeting credentials in the LSASS process owing to the fact that it "can store not only a current user's OS credentials but also a domain admin's."

"Dumping LSASS credentials is important for attackers because if they successfully dump domain passwords, they can, for example, then use legitimate tools such as PsExec or Windows Management Instrumentation (WMI) to move laterally across the network," the tech giant said.

Found this article interesting? Follow THN on Facebook, Twitter __ and LinkedIn to read more exclusive content we post.

Iranian Hackers Compromised a U.S. Federal Agency’s Network Using Log4Shell Exploit

Autocompleted code is convenient and quick, but it may expose your organization to security and compliance risks.

In recent months, we've marveled at the quality of computer-generated faces, cat pictures, videos, essays, and even art. Artificial intelligence (AI) and machine learning (ML) have also quietly slipped into software development, with tools like GitHub Copilot, Tabnine, Polycode, and others taking the logical next step of putting existing code autocomplete functionality on AI steroids. Unlike cat pics, though, the origin, quality, and security of application code can have wide-reaching implications — and at least for security, research shows that the risk is real.

Prior academic research has already shown that GitHub Copilot often generates code with security vulnerabilities. More recently, hands-on analysis from Invicti security engineer Kadir Arslan showed that insecure code suggestions are still the rule rather than the exception with Copilot. Arslan found that suggestions for many common tasks included only the absolute bare bones, often taking the most basic and least secure route, and that accepting them without modification could result in functional but vulnerable applications.

A tool like Copilot is (by design) autocompletion turned up a notch, trained on open source code to suggest snippets that could be relevant in a similar context. This makes the quality and security of suggestions closely tied to the quality and security of the training set. So the bigger questions are not about Copilot or any other specific tool but about AI-generated software code in general.

It's reasonable to assume Copilot is only the tip of the spear and that similar generators will become commonplace in the years ahead. This means we, the technology industry, need to start asking how such code is being generated, how it's used, and who will take responsibility when things go wrong.

**Satnav Syndrome**

Traditional code autocompletion that looks up function definitions to complete function names and remind you what arguments you need is a massive time-saver. Because these suggestions are merely a shortcut to looking up the docs for yourself, we've learned to implicitly trust whatever the IDE suggests. Once an AI-powered tool comes in, its suggestions are no longer guaranteed to be correct — but they still feel friendly and trustworthy, so they are more likely to be accepted.

Especially for less experienced developers, the convenience of getting a free block of code encourages a shift of mindset from, "Is this code close enough to what I would write" to, "How can I tweak this code so it works for me."

GitHub very clearly states that Copilot suggestions should always be carefully analyzed, reviewed, and tested, but human nature dictates that even subpar code will occasionally make it into production. It's a bit like driving while looking more at your GPS than the road.

**Supply Chain Security Issues**

The Log4j security crisis has moved software supply chain security and, specifically, open source security into the limelight, with a recent White House memo on secure software development and a new bill on improving open source security. With these and other initiatives, having any open source code in your applications could soon need to be written into a software bill of materials (SBOM), which is only possible if you knowingly include a specific dependency. Software composition analysis (SCA) tools also rely on that knowledge to detect and flag outdated or vulnerable open source components.

But what if your application includes AI-generated code that, ultimately, originates from an open source training set? Theoretically, if even one substantial suggestion is identical to existing code and accepted as-is, you could have open source code in your software but not in your SBOM. This could lead to compliance issues, not to mention the potential for liability if the code turns out to be insecure and results in a breach — and SCA won't help you, as it can only find vulnerable dependencies, not vulnerabilities in your own code.

**Licensing and Attribution Pitfalls**

Continuing that train of thought, to use open source code, you need to comply with its licensing terms. Depending on the specific open source license, you will at least need to provide attribution or sometimes release your own code as open source. Some licenses forbid commercial use altogether. Whatever the license, you need to know where the code came from and how it's licensed.

Again, what if you have AI-generated code in your application that happens to be identical to existing open source code? If you had an audit, would it find that you are using code without the required attribution? Or maybe you need to open source some of your commercial code to remain compliant? Perhaps that's not yet a realistic risk with current tools, but these are the kind of questions we should all be asking today, not in 10 years' time. (And to be clear, GitHub Copilot does have an optional filter to block suggestions that match existing code to minimize supply chain risks.)

**Deeper Security Implications**

Going back to security, an AI/ML model is only as good (and as bad) as its training set. We've seen that in the past — for example, in cases of face recognition algorithms showing racial biases because of the data they were trained on. So if we have research showing that a code generator frequently produces suggestions with no consideration for security, we can infer that this is what its learning set (i.e., publicly available code) was like. And what if insecure AI-generated code then feeds back into that code base? Can the suggestions ever be secure?

The security questions don't stop there. If AI-based code generators gain popularity and start to account for a meaningful proportion of new code, it's likely somebody will try to attack them. It's already possible to fool AI image recognition by poisoning its learning set. Sooner or later, malicious actors will try to put uniquely vulnerable code in public repositories in the hope that it comes up in suggestions and eventually ends up in a production application, opening it up to an easy attack.

And what about monoculture? If multiple applications end up using the same highly vulnerable suggestion, whatever its origin, we could be looking at vulnerability epidemics or maybe even AI-specific vulnerabilities.

**Keeping an Eye on AI**

Some of these scenarios may seem far-fetched today, but they are all things that we in the tech industry need to discuss. Again, GitHub Copilot is in the spotlight only because it currently leads the way, and GitHub provides clear warnings about the caveats of AI-generated suggestions. As with autocomplete on your phone or route suggestions in your satnav, they are only hints to make our lives easier, and it's up to us to take them or leave them.

With their potential to exponentially improve development efficiency, AI-based code generators are likely to become a permanent part of the software world. In terms of application security, though, this is yet another source of potentially vulnerable code that needs to pass rigorous security testing before being allowed into production. We're looking at a brand new way to slip vulnerabilities (and potentially unchecked dependencies) directly into your first-party code, so it makes sense to treat AI-augmented codebases as untrusted until tested — and that means testing everything as often as you can.

Even relatively transparent ML solutions like Copilot already raise some legal and ethical questions, not to mention security concerns. But just imagine that one day, some new tool starts generating code that works perfectly and passes security tests, except for one tiny detail: Nobody knows how it works. That's when it’s time to panic.

Are We Ready for AI-Generated Code?

Testing is an ongoing mission, not a one-and-done fix.

Cybersecurity must evolve beyond reactively handling breaches and pivoting to protect an organization's data after the fact. Without proper precautions, cybercriminals from all over the world can easily take advantage of vulnerabilities within a company's Web applications, mobile applications, APIs, and more. Penetration testing, also known as pen testing, is a method of cybersecurity in which an expert plays the role of a malicious actor to expose the holes and flaws within a security infrastructure or codebase. 

Pen testing is primarily facilitated by dedicated pen testers — some hired internally and others externally through an agency or freelance service. My six years at Cobalt have taught me new, unique, and hidden best practices. It's my ongoing mission and commitment to spread my knowledge and lessons with other security executives to enhance organizations' protection efforts.

**What Is the Goal of Pen Testing?**

Simply put, penetration testing is when a dedicated group of cybersecurity professionals simulate different cyberattacks on an application or network to test for potential vulnerabilities. The goal is to improve the security posture of an organization and discover easily exploitable vulnerabilities within a security system so the company can proactively fix them. Bugs are bound to occur, but being aware of where vulnerabilities lie can polish your product and tighten up your security. 

While many companies invest heavily in building up their infrastructure, the majority of the steps needed to protect investments happen _after_ deployment. Thus, companies are left with a reactive response in place, addressing breaches and attacks on their network once it's too late. Given the fact that cyberattacks have the potential to ripple both internally and externally, leaders must take a proactive approach to cybersecurity, developing at-the-ready responses to squash incoming threats as they appear.

The merits of pen testing come into the limelight once organizations recognize the cycle of destruction caused by cyberattacks. This cycle entails more than the data potentially stolen. It involves the time not only to address the initial vulnerability but to recover and secure any data that could have been potentially stolen. Needless time and resources are spent cleaning up the mess, rather than developing new code. A cycle develops wherein an organization launches new code into their network, an unforeseen vulnerability shows up, and the team has to scramble to fix the issue before it grows even larger. By taking the necessary steps before the new code goes into production, companies can remove themselves from this vicious circle of destruction.

According to Cobalt's "State of Pentesting Report 2021," pen testing can be a time-consuming task. In fact, 55% of organizations said it takes weeks to get a pen test scheduled, with 22% saying it takes months. Modern pen testing practices use both automated tools and skilled manual testers to ensure maximum security in an efficient and timely fashion. Staying agile in your organization's cybersecurity practices will help cut down on the amount of time it takes to schedule the proper precautions.

**What Are the Outside Benefits?**

Pen testing has benefits outside of just vulnerability identification. Code often is dependent on other code, so frequent pen testing allows for new code to be tested before it's deployed into the live build, thus streamlining the development process and lowering development costs. Frequent pen testing also provides more timely results, enabling teams to be at the ready for emerging threats — compared with the standard annual pen test, where developers won't be aware of vulnerabilities for months on end. 

In 2021, many security professionals had to quickly respond to the Log4j threat, but those who frequently pen tested were prepared to patch the exploitable vulnerabilities it caused. Due to the insight these developers obtained from previous pen tests, future code will become more secure, and engineers will learn from mistakes when developing future versions of their products. The more often these pen tests happen, the more compliant your products and code will become.

**When to Schedule a Pen Test**

The best time to schedule a pen test is — of course — before an attack occurs. While we cannot predict exactly when a breach will come, staying proactive and regularly testing and retesting vulnerabilities can save the company from a vicious cyberattack. Organizations can use pen testing to prepare new products, updates, and tools for customer or employee use, all while staying compliant and secure. But for those products to safely go into the hands of the intended audience, they need to be tested.

Proactivity starts with internally evaluating where vulnerabilities already exist within a security system. If discovered early, these vulnerabilities can be dealt with before they take on a life of their own — ultimately saving the company's reputation. Take note of all of the assets your team has (websites, servers, live code, etc.), and set a clear plan for exposure detection. Once your team is clear on the future strategy and practices, your pen testers can begin identifying and exposing the vulnerabilities that may be in your company's resources. Once the test is concluded, developers can start remediating any discovered vulnerabilities.

The important takeaway here is, these tests should not be performed on a one-and-done basis. Pen tests must be executed regularly to ensure security remains up to date with modern breaching methods. Cybersecurity changes (and becomes more complex) each day, forcing organizations to be ready for what's to come at a moment's notice.

How Routine Pen Testing Can Reveal the Unseen Flaws in Your Cybersecurity Posture

BatLoader has spread rapidly to roost in systems globally, tailoring payloads to its victims.

A dangerous new malware loader with features for determining whether it's on a business system or a personal computer has begun rapidly infecting systems worldwide over the past few months.

Researchers at VMware Carbon Black are tracking the threat, dubbed BatLoader, and say its operators are using the dropper to distribute a variety of malware tools including a banking Trojan, an information stealer, and the Cobalt Strike post-exploit toolkit on victim systems. The threat actor's tactic has been to host the malware on compromised websites and lure users to those sites using search engine optimization (SEO) poisoning methods.

**Living Off the Land**

BatLoader relies heavily on batch and PowerShell scripts to gain an initial foothold on a victim machine and to download other malware onto it. This has made the campaign hard to detect and block, especially in the early stages, analysts from VMware Carbon Black's managed detection and response (MDR) team said in a report released on Nov. 14.

VMware said its Carbon Black MDR team had observed 43 successful infections in the last 90 days, in addition to numerous other unsuccessful attempts where a victim downloaded the initial infection file but did not execute it. Nine of the victims were organizations in the business services sector, seven were financial services companies, and five were in manufacturing. Other victims included organizations in the education, retail, IT, and healthcare sectors.

On Nov. 9, eSentire said its threat-hunting team had observed BatLoader's operator luring victims to websites masquerading as download pages for popular business software such as LogMeIn, Zoom, TeamViewer, and AnyDesk. The threat actor distributed links to these websites via ads that showed up prominently in search engine results when users searched for any of these software products.

The security vendor said that in one late October incident, an eSentire customer arrived at a fake LogMeIn download page and downloaded a Windows installer that, among other things, profiles the system and uses the information to retrieve a second-stage payload.

"What makes BatLoader interesting is that it has logic built into it that determines if the victim computer is a personal computer or a corporate computer," says Keegan Keplinger, research and reporting lead with eSentire’s TRU research team. "It then drops the type of malware appropriate for the situation."

**Selective Payload Delivery**

For example, if BatLoader hits a personal computer, it downloads Ursnif banking malware and the Vidar information stealer. If it hits a domain-joined or corporate computer, it downloads Cobalt Strike and the Syncro remote monitoring and management tool, in addition to the banking Trojan and information stealer.

"If BatLoader lands on a personal computer, it will proceed with fraud, infostealing, and banking-based payloads like Ursnif," Keegan says. "If BatLoader detects that it's in an organizational environment, it will proceed with intrusion tools like Cobalt Strike and Syncro."

Keegan says eSentire has observed "a lot" of recent cyberattacks involving BatLoader. Most of the attacks are opportunistic and hit anyone looking for trusted and popular free software tools. 

"To get in front of organizations, BatLoader leverages poisoned ads so that when employees look for trusted free software, like LogMeIn and Zoom, they instead land on sites controlled by attackers, delivering BatLoader."

**Overlaps With Conti, ZLoader**

VMware Carbon Black said that while there are several aspects of the BatLoader campaign that are unique, there are also several attributes of the attack chain that have a resemblance with the Conti ransomware operation. 

The overlaps include an IP address that the Conti group used in a campaign leveraging the Log4j vulnerability, and the use of a remote management tool called Atera that Conti has used in previous operations. 

In addition to the similarities with Conti, BatLoader also has several overlaps with Zloader, a banking Trojan that appears derived from the Zeus banking Trojan of the early 2000s, the security vendor said. The biggest similarities there include the use of SEO poisoning to lure victims to malware-laden websites, the use of Windows Installer for establishing an initial foothold and the use of PowerShell, batch scripts, and other native OS binaries during the attack chain.

Mandiant was the first to report on BatLoader. In a blog post in February, the security vendor reported observing a threat actor using "free productivity apps installation" and "free software development tools installation" themes as SEO keywords to lure users to download sites. 

"This initial BatLoader compromise was the beginning of a multi-stage infection chain that provides the attackers with a foothold inside the target organization," Mandiant said. The attackers used every stage to set up the next phase of the attack chain using tools such as PowerShell, Msiexec.exe, and Mshta.exe to evade detection.

Researchers Sound Alarm on Dangerous BatLoader Malware Dropper

AppSec engineer keynote says Log4j revealed lessons were not learned from the Equifax breach

Adam Bannister 14 November 2022 at 16:16 UTC  
Updated: 14 November 2022 at 16:54 UTC

AppSec engineer keynote says Log4j revealed lessons were not learned from the Equifax breach

Shutting the proverbial back door to your networks “cuts the risks \[of attacks\] down tremendously”, said application security engineer Sean Wright at Friday’s All Day DevOps.

The keynote speaker urged security teams to have “appropriate access controls in place” in order to protect themselves against a 742% rise in ‘next generation’ supply chain attacks, a threat that has mushroomed since the SolarWinds incident rocked the open source ecosystem in December 2020.

Among other techniques, attackers are leveraging typosquatting, dependancy confusion, malicious code injections, vulnerabilities within packages, protestware, and takeovers of package author accounts (the latter prompting package managers to implement multi-factor authentication (MFA)).

RELATED Researchers find 633% increase in cyber-attacks aimed at open source repositories

“Make sure that your servers are really well defined \[in terms of\] what and who they can speak to”, said Wright, who re-recorded his virtual keynote presentation after technical hiccups cut his live appearance short.

“Your servers should never, never ever have open outbound access”, Wright advised.

Many modern supply chain attacks “leverage the fact that many organizations do filter things coming in, but they never pay any attention to what’s going out”, added Wright.

**Swimming upstream**

The dramatic increase in the size of the open source ecosystem has persuaded attackers to diversify beyond attacking applications to targeting their upstream components too, he noted. If anything, Wright was surprised they did not do this sooner and at greater scale.

For context, his own research indicated that between 2015 and 2022 there had been trillions of download requests across various package managers, with Java downloads soaring 3,870%, JavaScript rising 13,900%, and .NET jumping 34,100%.

When a typical app has 20-30 dependencies, which themselves will often have 5-10 dependencies with something like 10,000 lines of code each, finding vulnerabilities is not so much a ‘needle in a haystack’ problem but a “needle in an open ocean” challenge, according to Wright.

AppSec engineer Sean Wright demonstrates dramatic growth in the open source ecosystem

Resources such as Google’s Open Source Insights are therefore invaluable. This “awesome” tool builds dependency graphs for open source packages, and annotates them with ownership, license, popularity, and other metadata.

Wright also recommended using Dependancy Track for a centralized view of your software bills of materials (SBOMs).

When a vulnerability surfaces, he advised security teams to pay attention to the vector more than the severity score, since the CVSS rating often changes as understanding of a bug deepens.

**Purge your build system**

The former software developer warned that, while package managers are quick to remove rogue packages from public repos, their use of caching means developers should “purge” their private repos and local build systems.

He praised a raft of recent initiatives around bolstering the software supply chain – SLSA, Sigstore Cosign, NIST guidance, and OSSF Security Scorecards – but despite these resources there remains much work to do.

Read more of the latest software supply chain attack news

After all, the critical Log4j bug showed that organizations had failed to heed the lesson offered by the Apache Struts bug that thrashed Equifax’s reputation in 2017 – “we’re finding 33% of downloads are still the vulnerable version”, he lamented.

“You wouldn’t typically allow any random stranger to commit code to your codebase,” Wright concluded. “But when we’re pulling down packages from random developers that’s exactly what we’re doing.”

All Day DevOps is a 24-hour software developer-focused conference. Presentations are still available to view on demand.

DON’T MISS Passport-SAML auth bypass triggers fix of critical, upstream XMLDOM bug

Tag

#log4j