Cyberattackers Hit Data of 80K Patients at Fertility Centers of Illinois

 

Description

The protected health information of nearly 80,000 patients of Fertility Centers of Illinois (FCI) may have been pawed over by cyber intruders following a cyberattack.

FCI runs four clinics across Illinois. According to the U.S. Department of Health and Human Services (HHS) Office for Civil Rights’ data breach site, the breach – reported on Dec. 27 – affected 79,943 people.

FCI’s data breach notice (PDF) said that the healthcare organization first detected suspicious activity on its internal systems on Feb. 1, 2021. A subsequent investigation indicated that security systems had blocked attackers from accessing patient EMR (electronic medical records) systems. However, the intruder(s) managed to access administrative files and folders.

FCI said that it immediately launched a “thorough and comprehensive review” of its records to identify the files accessed, the information contained in those files and the individuals to whom that information pertained.

By Aug. 27, 2021, FCI had determined that information related to certain FCI patients was included in the set of files that had been improperly accessed. One positive finding so far: FCI said it’s “not aware of any actual or attempted misuse of patient information as a result of this incident.”

May it stay that way, given the severe harm that could be done with the dizzying array of highly sensitive personally identifying information (PII) that was involved: a trove that could be mined for financial fraud, identity theft, healthcare fraud and more.

A Treasure Trove of Compromised Data

The accessed files included some patients’ names, employer-assigned ID numbers, passport numbers, Social Security numbers, financial account information, payment card information, treatment information, diagnosis, treating/referring physicians, medical record number, medical billing/claims information, prescription/medication information, Medicare/Medicaid identification information, health insurance group numbers, health insurance subscriber numbers, patient account numbers, encounter numbers, ill health/retirement information, master patient index, occupational-health related information, other medical benefits and entitlements information, other medical ID numbers, patkeys/reason for absence, sickness certificate, usernames and passwords with PINs or account login information, and medical facilities associated with patient information.

The Big Business of Extremely Intimate Data

Stealing this kind of data is big business. One example: In October, a Las Vegas man and former medical records tech was sentenced to 12.5 years of prison for stealing PII that was then used to fraudulently claim Department of Defense (DoD) and Veterans Administration (VA) benefits, particularly targeting disabled veterans.

The data of more than 3,300 U.S. military service members, military dependents and civilians employed by the DoD were compromised as part of what turned out to be a transnational cybercrime ring created to defraud them out of $1.5 million in military benefits from the DoD and the VA.

With regards to the FCI breach, the organization said that it immediately took steps to eliminate unauthorized access and brought in independent forensic investigators to investigate and remediate the matter, on top of additional security measures meant to further secure access to data, individual accounts, and equipment, including the implementation of enterprise identity verification software.

FCI has also bolstered employee security practices training and has offered a year’s worth of free credit monitoring and identity theft protection through Equifax.

“Please be assured that we have invested considerable resources to ensure that such a vulnerability does not exist in the future,” FCI concluded.

The New Year Has Had a Lot of Picking On Patients

Easier said than done, apparently. Unfortunately, the new year has ushered in an undiminished zest for attacking healthcare information.

Earlier this week, Florida’s Broward Health System announced that the most intimate medical data of 1,357,879 patients was breached in October: evidence of what security researchers said is a soft-bellied healthcare software supply chain that’s proved to be a juicy target for cybercriminals.

Healthcare organizations are also in the same log-jammed boat as every other sector: They’re hyper-focused on mitigating threats associated with the Apache Log4j vulnerability and trying to avoid the disastrous consequences if the Log4Shell flaws are exploited.

Earlier this week, Microsoft reported that it saw rampant Log4j exploit attempts and testing through the end of December.

The Acute Danger of Log4j for Healthcare

On Dec. 17, a week after the discovery of the Log4j flaw, the HHS 405(d) Task Group issued a brief (PDF) outlining the risks associated with the vulnerability that could have catastrophic security implications for healthcare and other sectors.

“The exploitation allows the execution of any code which could result in compromise of the server, download of malicious binaries, or propagation of further attacks such as ransomware or a zero-day attack,” according to HHS’s alert.

It’s not even clear how many healthcare systems and devices could be affected by Log4Shell or what all the ways of exploitation might be, but it’s estimated that it could potentially affect hundreds of millions of devices, networks and/or software platforms, HHS said.

“Healthcare organizations are dependent on readily available devices and software that are vendor-supplied and connected to an external network to operate. These complex and interconnected devices affect patient safety and privacy,” according to HHS.

“They represent potential attack vectors across an organization like medical equipment such as bedside monitors that monitor vital signs during an inpatient stay,” the alert continued. “Or, they may be more complicated, like infusion pumps that deliver specialized therapies and require continual drug library updates. If an attacker gained access to the network through a vulnerability such as Log4j, they would be able to gain control of the software and could potentially disconnect devices from the network, therefore, causing a disruption to daily procedures and putting patient safety at risk.”

HHS explained that mainstream and well-known organizations, including cloud services, use Log4j software and may be vulnerable, including cloud applications that medical organizations use for Electronic Health Records (EHR) services and outsourced security services such as Software as a Service (SaaS).

Github maintains a running list of affected services and products.

Admin Account Used to Get at Data

Ben Pick, Principal Consultant at app security provider nVisium, noted that FCI stated that it followed reasonable practices to protect users and that an administrative account was used to obtain the data: the privileged kind of account from which attackers can do beaucoup damage. “These higher privileged accounts often have access to widespread data and act as a single point of failure, as evidenced by the large amount of user data exposed,” he told Threatpost via email.

His advice, in lieu of knowing the cause of the administrator’s account being compromised, is to limit access rights based on need to know.

Failing that, monitor, monitor, monitor, Pick advised: “When these privileged accounts cannot be limited, then strong monitoring must be enforced. This would alert when anomalous calls are made to indicate when an administrator may be performing an excessive amount of searches and possibly exfiltrating data.”

The Soft Spot of APIs

Mac McMillan, CEO of CynergisTek, predicted in an interview with HealthITSecurity that in the new year, ransomware operators will shift their focus away from encryption and on to data exfiltration.

Blame the soft spot of APIs, he said: “As interoperability becomes more of a mainstream priority for healthcare organizations and we see more APIs that are being introduced between critical systems, I think we’re going to see a rise in the number of attacks that are focused on compromising those APIs.

“It’s another area where [we] don’t typically have a good, consistent approach across the board in healthcare with respect to testing APIs for security.”

This is particularly true given that healthcare organizations are now looking at an API change-over deadline: By year’s end – Dec. 31, 2022 – they’re required to migrate to Fast Healthcare Interoperability Resources (FHIR) APIs in order to enable seamless data sharing. Implementing the new data standards will likely cause enough turmoil that threat actors will be that much more attracted to APIs as a network entry point, McMillan suggested.

Why Was FCI’s Regulated Data Outside of Network Monitoring?

Jake Williams, Co-Founder and CTO at incident response firm BreachQuest, noted to Threatpost on Friday that it’s not uncommon for medical organizations to store patient data outside of their EHR system, and it sounds like that’s what happened here.

“As the article notes, the EMR was not compromised due to unspecified security measures,” Williams said via email.

“However, files (presumably on some network share) were accessed by threat actors. It wouldn’t surprise me to learn that the EMR enforces [multi-factor authentication] or doesn’t use domain authentication.”

Williams suggested that organizations take inventory of where they may have regulated data that may fall outside of normal monitoring and audit controls: a topic that Citrix iterated in a September sponsored article on Threatpost.

“Those who don’t perform regular data inventory searches almost certainly have regulated data in their file shares – a location where it is just one phishing email away from compromise,” Williams said.

_Photo courtesy of _Marko Milivojevic via Pixnio. Licensing details.

Read More

Log4Shell Strategic Response: 5 Practices for Vulnerability Management at Scale

 

Description

This post is co-authored by Blake Cifelli, Senior Advisory Services Consultant.

In today’s cybersecurity world, risks evolve faster than we can remediate them. To meet our goals and become resilient to these fast changes, we need the right balance of automation and human interaction. Enabling rapid response for protecting information systems is paramount, but how does a business reach this level of reaction?

How can organizations maintain a standard of excellence to their responses in high-risk situations?

Where do you even begin to respond to a critical vulnerability like the one in Apache’s Log4j Java library (a.k.a. Log4Shell)?

Most importantly, how do we transform the tactical actions that need to take place into an effective strategy to scale?

1. Empower personnel

The personnel with the knowledge about your various solutions must be empowered to make the decisions necessary to address your company’s information technology needs. If those team members don’t feel they can make those decisions, then they will defer to management — but managers may not know the intricacies of the solutions and could create a natural bottleneck, since there are going to be more decision points than managers to make decisions. Providing personnel with policy documents with uniform criteria for evaluating the risk these new vulnerabilities present, the ways to respond, and the time expectations is paramount for a timely resolution.

In a typical risk resolution process, there are many gates to safeguard our systems. This helps ensure that whatever change happens increases the solution’s confidentiality, integrity, or availability rather than diminishing it. However, a situation like Log4Shell needs to be treated like an incident response activity to quickly address the risk. Create a task force to effectively answer the important questions like:

• How do we find vulnerable systems?
• Which systems are vulnerable?
• What options are there for a fix? One size may not fit all.
• Who is going to track changes?
• Who is going to validate the fix is in place?

Utilizing a strong incident response procedure to answer all these questions will assist with prioritization and remediation to an acceptable level of risk.

2. Promote visibility

Any standard vulnerability management lifecycle process begins with identifying affected systems to assess and evaluate the scope of a vulnerability’s presence on the network. The approach should utilize both proactive and reactive efforts through a combination of tools and well-documented processes to streamline and scale the response effectively.

A proactive process would first involve having well-documented use of any such library versions internally in an inventory, so that discoverability and traceability are much more narrowly focused efforts. If you conduct authenticated vulnerability scans continuously on pre-scheduled frequencies, this will also help with identification of third-party software utilizing this library over time. Classifying system criticality within the vulnerability management tool will help you more effectively scale future remediation processes.

These proactive processes help jumpstart an initial response, but you’ll still need reactive efforts to help ensure effective and timely remediation. Vulnerability scanning tools will receive signature updates regarding this newly discovered vulnerability, which will require updating your vulnerability management tool and initiating one-off alternative scans that may deviate from pre-scheduled rotations. These alternative scans should include tiered phases, so the most critical systems receive scan priority, and then remaining systems are scanned in order of criticality. Leveraging the pre-existing system criticality classification will significantly expedite this process.

A security incident and event management (SIEM) tool can also assist with identifying, tracking, and alerting for any suspicious activity that may be tied to exploitation of this vulnerability. Host agents and network detection systems that report back to the SIEM should be closely monitored, and any activity or traffic that deviates from baselines should receive an active response. You may need to adjust logging and alerting rules and thresholds to ensure your efforts are strategically focused.

Tactical processes help you achieve this continuous identification, but you still need to orchestrate and execute them through strategic planning to remain timely, efficient, and effective. Well-documented asset inventories and appropriate system criticality classifications help you prioritize your efforts, while continuous vulnerability scans and leveraging vulnerability management and SIEM tools help to identify, track, and manage vulnerability exposure. Leadership should provide the direction to guide these activities from inception to implementation through effective communication and allocation of resources. Lay out a short-term roadmap for tracking objectives and quick wins as part of the remediation process, so you can quickly and concisely show how you’re tracking toward goals.

3. Implement prioritization and mitigation

Now that your team has successfully identified all affected systems, you’ll need to roll out patches to those systems on a continuous basis during the next phase to mitigate risk. Current enterprise-wide patching timelines may require adjustment due to the urgency associated with such critical vulnerabilities. Patch testing and rollout phases must be expedited to support a more timely and effective response.

Much like conducting our vulnerability scans in terms of system criticality prioritization, our patch management response should follow a similar approach, with the caveat that a pilot group or pilot system deemed non-critical should be patched first for testing purposes to ensure no adverse effects prior to rolling out patches in order of system criticality. If you’ve configured a full test environment is configured, you can test patches on critical systems first within that environment and then roll them out in production according to criticality. The testing timeline itself should be reduced throughout all standard phases of a testing cycle — you may even need to eliminate certain testing phases altogether. The rollout timelines for patches across all systems will need to be expedited as well to ensure as timely coverage as possible. If your environment has widespread use of the vulnerable library, you may require reductions in timelines of anywhere from 25% to 50%.

Emergency patching procedures should provide for timely testing and production rollouts within roughly half the time of a normal patching cycle, or 5 to 10 days at a maximum for critical systems to minimize breach potential as quickly as possible. Also keep in mind that some vulnerabilities may involve more than just application of a simple patch — configuration changes may also be necessary to further mitigate potential exploitation by an adversary.

4. Validate remediation

Now, you’ve deployed patches to all affected systems, so the mitigation efforts are complete, right? While you may want to shift your focus back to other tasks, it’s essential to maintain continuous identification processes to ensure that no stone remains unturned.

The vulnerability management validation phase leverages those reactive identification processes, in addition to patch management processes, to assist in efficient and effective vulnerability remediation for affected systems. This stage involves re-scanning initially identified vulnerable systems to assess successful patch application and performing additional open scans of the network to ensure that there are no lingering systems that may still be affected by the vulnerability but weren’t originally identified — or perhaps weren’t successfully patched as part of the patch management process. This cycle of continuous validation will remain in effect until “clean” scans are reported across the enterprise regarding this vulnerability.

Since the Log4j logging library is widely used throughout many enterprise applications and even unknowingly embedded in so many others, continuous validation will become crucial in ensuring your organization remains vigilant and can mitigate the vulnerability quickly and effectively as you continue to discover affected systems.

5. Regularly review risks

A vulnerability management lifecycle rarely ever comes to a true end. As adversaries and security evangelists further evaluate a specific vulnerability over time, new methods of exploitation are identified, affected versions increase in scope and scale, and recent patches and fixes are found to be ineffective. This leaves organizations potentially open to exposure and at a loss for the best path forward. Continuous review of the trends surrounding an ongoing critical vulnerability will help organizations ensure they remain both aware of the impact and the current mitigating measures that have been most successful. Additionally, leveraging other solutions can help further identify and launch a coordinated defense-in-depth response to any potential malicious activity that may be associated with such vulnerabilities.

Working to continuously identify, mitigate, validate, and review vulnerabilities throughout their inevitable course will require commitment and fortitude to achieve the best results, but once the tides have subsided with Log4Shell and you’ve successfully and securely endured one of the worst security vulnerability exposures in a decade by following these processes, you can rest assured that your incident response processes were well-tested during this endeavor — and your IT security budget should be more than solidified for the next few years to come.

Check out our additional resources for further insight of this vulnerability, mitigating measures, and tools available to assist.

• Log4Shell Resource Hub
• Log4Shell Resources for Rapid7 Customers
• Widespread Exploitation of Critical Remote Code Execution in Apache Log4j
• Update on Log4Shell’s Impact on Rapid7 Solutions and Systems
• Using InsightVM to Find Apache Log4j CVE-2021-44228
• InsightVM Docs page for Log4j
• Rapid7 analysis of Log4Shell on AttackerKB

NEVER MISS A BLOG

Read More

Metasploit Wrap-Up

 

Description

Dump Windows secrets from Active Directory

This week, our very own Christophe De La Fuente added an important update to the existing Windows Secret Dump module. It is now able to dump secrets from Active Directory, which will be very useful for Metasploit users. This new feature uses the Directory Replication Service through RPC to retrieve data such as SIDs, password history, Domain user NTLM hashes and Kerberos keys, etc. This replicates the behavior of the famous impacket secretsdump.py, with the benefit of being fully integrated with Metasploit Framework. For example, it is possible to pivot on a compromised host and run the Windows Secret Dump module against an internal Domain Controller directly from msfconsole. Furthermore, the secrets are stored in the internal database, which lets other modules access this information easily.

This update also brings another big improvement to the ruby_smb library. This adds a new DCERPC client and many ready-to-use RPC queries from Directory Replication Service (DRS) Remote Protocol, Security Account Manager (SAM) Remote Protocol and Workstation Service Remote Protocol. These will greatly simplify the process of writing modules that use DCERPC against Windows systems.

Authenticated Catch Themes Demo Import Remote Code Execution

Thank you to Ron Jost, Thinkland Security Team, and h00die for their community contribution of a Remote Code Execution exploit module against versions 1.8 and earlier of the Catch Themes Demo Import Wordpress Plugin.

New module content (6)

• Grafana Plugin Path Traversal by h00die and jordyv, which exploits CVE-2021-43798 - This aAdds a module to exploit Grafana file read vulnerability CVE-2021-43798.
• Native LDAP Server (Example) by RageLtMan and Spencer McIntyre - This adds the initial implementation of an LDAP server implemented in Rex and updates the existing log4shell scanner module to use it as well as provides a new example module.
• Wordpress Plugin Catch Themes Demo Import RCE by Ron Jost, Thinkland Security Team, and h00die, which exploits CVE-2021-39352 - This adds an exploit for the Catch Themes Demo Import Wordpress plugin for versions below 1.8. The functionality for importing a theme does not properly sanitize file formats, allowing an authenticated user to upload a php payload. Requesting the uploaded file achieves code execution as the user running the web server.
• Wordpress Popular Posts Authenticated RCE by Jerome Bruandet, Simone Cristofaro, and h00die, which exploits CVE-2021-42362 - This PR adds a new exploit for wp_popular_posts <=5.3.2.
• ManageEngine ServiceDesk Plus CVE-2021-44077 by wvu and Y4er, which exploits CVE-2021-44077
• Dell DBUtilDrv2.sys Memory Protection Modifier by Jacob Baines, Kasif Dekel, Red Cursor, and SentinelLabs - This module leverages a write-what-where condition in DBUtilDrv2.sys version 2.5 or 2.7 to disable or enable LSA protect on a given PID (assuming the system is configured for LSA Protection). The drivers must be provided by the user.

Enhancements and features

• #15831 from zeroSteiner - Established SSH connections can now leverage the pivoting capabilities of the SshCommandShellBind session type.
• #15882 from smashery - An update has been made which will prevent exploits from running a payload if the exploit drops files onto the target, but the payload doesn’t have the capability to clean those dropped files up from the target. Users can still override this setting by specifying set AllowNoCleanup true if they wish to bypass this protection.
• #15924 from cdelafuente-r7 - This adds the NTDS technique to the Windows Secrets Dump module, enabling it to be used against Domain Controllers. It also pulls in RubySMB changes that include many DCERPC related improvements and features.
• #15986 from bcoles - Module notes added to bash_profile_persistence now describe impacts of utilizing the module in a target environment.

Bugs fixed

• #15982 from 3V3RYONE - This fixes a bug where modules using the SMB client would crash when the SMBUser datastore option had been explicitly unset.
• #15984 from h00die - This PR fixes a bug in the snmp library which caused it to ignore version 1, despite specifically set options.
• #16003 from jmartin-r7 - This fixes an issue with GitHub actions where the Ruby 3.1.0 version string is not yet being parsed correctly leading to automation failures.
• #16015 from zeroSteiner - This fixes a regression in tab completion for the RHOSTS datastore option.

Get it

As always, you can update to the latest Metasploit Framework with msfupdate
and you can get more details on the changes since the last blog post from
GitHub:

• Pull Requests 6.1.20…6.1.23
• Full diff 6.1.20…6.1.23

If you are a git user, you can clone the Metasploit Framework repo (master branch) for the latest.
To install fresh without using git, you can use the open-source-only Nightly Installers or the
binary installers (which also include the commercial edition).

Read More

Log4J-Related RCE Flaw in H2 Database Earns Critical Warning

 

Description

Researchers discovered a bug related to the Log4J logging library vulnerability, which in this case opens the door for an adversary to execute remote code on vulnerable systems. However, this flaw does not pose the same risk as the previously identified in Log4Shell, they said.

JFrog security discovered the flaw and rated critical in the context of the H2 Java database console, a popular open-source database, according to a Thursday blog post by researchers.

H2 is attractive to developers for its lightweight in-memory solution–which precludes the requirement for data to be stored on disk—and is used in web platforms such as Spring Boot and IoT platforms such as ThingWorks.

However, the flaw (CVE-2021-42392) is similar to Log4Shell. “[I]t should not be as widespread” due to a few conditions and factors, JFrog researchers Andrey Polkovnychenko and Shachar Menashe wrote in their post.

Log4Shell (CVE-2021-44228) was tied to the Apache Log4j logging library in early December and immediately exploited by attackers. It spawned 60 variants of the original exploit created for the flaw in a 24-hour period as well as a faulty fix that could cause DoS attacks when it was first released.

How is the H2 Bug Similar to Log4J?

The root cause of the H2 flaw is based in JNDI remote class loading, making it similar to Log4Shell in that it allows several code paths in the H2 database framework pass unfiltered attacker-controlled URLs to the javax.naming.Context.lookup function. This allows for remote codebase loading, also known as Java code injection or remote code execution, researchers said.

“Specifically, the org.h2.util.JdbcUtils.getConnection method takes a driver class name and database URL as parameters,” they explained in the post. “If the driver’s class is assignable to the javax.naming.Context class, the method instantiates an object from it and calls its lookup method.”

Reasons to Be Wary, but Not Panic

However, unlike Log4Shell, the H2 flaw has a “direct” scope of impact, meaning that typically the server that processes the initial request—that is, the H2 console—will feel the direct brunt of the remote code execution (RCE) bug, researchers wrote in a post published Thursday.

“This is less severe compared to Log4Shell since the vulnerable servers should be easier to find,” researchers wrote.

Secondly, by default on vanilla distributions of the H2 database, the H2 console only listens to localhost connections, thus making the default setting safe, they noted.

“This is unlike Log4Shell which was exploitable in the default configuration of Log4j,” researchers wrote. Still, the H2 console can easily be modified to listen to remote connections as well, which would widen the risk, researchers added.

Indeed, this aspect of the execution of the flaw definitely lessens its severity in comparison to the Log4j issue, noted one security professional.

“Log4j was unique in that any number of attack-manipulated strings, from headers to URL paths, could result in exploitation of the victim depending on how the application was set up to utilize logging with Log4j,” Matthew Warner, CTO and co-founder at automated threat detection and response technology provider Blumira, wrote in an email to Threatpost. “In this case, the H2 database console must be purposefully exposed to the internet by changing the configuration.”

Thirdly, while many vendors may be running the H2 database, they may not run the H2 console with it, JFrog researchers said. There are other attack vectors that can exploit the H2 flaw; however, they are “context-dependent and less likely to be exposed to remote attackers,” researchers observed.

Who Is At Risk?

If the H2 flaw doesn’t deserve the same alarm as Log4Shell, why is it worth noting, one may ask. The JFrog team said that it can be extremely critical and allow for unauthenticated RCE to those running an H2 console exposed to a local area network (LAN) or, even worse, a wide area network (WAN). Indeed, attacking the H2 console directly is the most severe attack vector, researchers said.

Blumira’s Warner said that according to open-source intelligence (OSINT), there are likely less than 100 servers on the internet impacted by the H2 flaw, “so only a very limited number of organizations” are directly affected, he said.

“This vulnerability is a good reminder that it is important to ensure that sensitive services are only internally exposed to mitigate potential future risks,” Warner added.

Still, JFrog researchers said that many developer tools rely on the H2 database and specifically expose the H2 console. This is worrying due to the “recent trend of supply chain attacks targeting developers, such as malicious packages in popular repositories.”

These attacks emphasize “the importance of developer tools being made secure for all reasonable use cases,” researchers wrote, which is why they hope many H2-dependent tools will be safer after applying their recommended fix.

On that point, the JFrog team recommends that all users of the H2 database to upgrade to version 2.0.206, which fixes CVE-2021-42392 by limiting JNDI URLs to use the local java protocol only, denying any remote LDAP/RMI queries, researchers explained.

“This is similar to the fix applied in Log4j 2.17.0,” they wrote.

Even those not directly using the H2 console should update “due to the fact that other attack vectors exist, and their exploitability may be difficult to ascertain,” researchers added.

Password****Reset: ****On-Demand Event: Fortify 2022 with a password-security strategy built for today’s threats. This Threatpost Security Roundtable, built for infosec professionals, centers on enterprise credential management, the new password basics and mitigating post-credential breaches. Join Darren James, with Specops Software and Roger Grimes, defense evangelist at KnowBe4 and Threatpost host Becky Bracken.Register & stream this FREE session today – sponsored by Specops Software.

Read More

Log4Shell-like Critical RCE Flaw Discovered in H2 Database Console

 

Description

Researchers have disclosed a security flaw affecting H2 database consoles that could result in remote code execution in a manner that echoes the Log4j “Log4Shell” vulnerability that came to light last month.

The issue, tracked as CVE-2021-42392, is the “first critical issue published since Log4Shell, on a component other than Log4j, that exploits the same root cause of the Log4Shell vulnerability, namely JNDI remote class loading,” JFrog researchers Andrey Polkovnychenko and Shachar Menashe said.

H2 is an open-source relational database management system written in Java that can be embedded within applications or run in a client-server mode. According to the Maven Repository, the H2 database engine is used by 6,807 artifacts.

JNDI, short for Java Naming and Directory Interface, refers to an API that provides naming and directory functionality for Java applications, which can use the API in conjunction with LDAP to locate a specific resource that it might need.

In the case of Log4Shell, this feature enables runtime lookups to servers, both inside and outside the network, which, in turn, can be weaponized to allow unauthenticated remote code execution and implant malware on the server by crafting a malicious JNDI lookup as input to any Java application that uses vulnerable versions of the Log4j library to log it.

“Similar to the Log4Shell vulnerability uncovered in early December, attacker-controlled URLs that propagate into JNDI lookups can allow unauthenticated remote code execution, giving attackers sole control over the operation of another person or organization’s systems,” Menashe, senior director of JFrog security research, explained.

The flaw affects H2 database versions 1.1.100 to 2.0.204 and has been addressed in version 2.0.206 shipped on January 5, 2022.

“The H2 database is used by many third-party frameworks, including Spring Boot, Play Framework and JHipster,” Menashe added. “While this vulnerability is not as widespread as Log4Shell, it can still have a dramatic impact on developers and production systems if not addressed accordingly.”

Read More

What's New in InsightIDR: Q4 2021 in Review

 

Description

****More context and customization around detections and investigations, expanded dashboard capabilities, and more.****

This post offers a closer look at some of the recent releases in InsightIDR, our extended detection and response (XDR) solution, from Q4 2021. Over the past quarter, we delivered updates to help you make more informed decisions, accelerate your time to respond, and customize your detections and investigations. Here’s a rundown of the highlights.

More customization options for your detection rules

InsightIDR provides a highly curated detections library, vetted by the security and operations center (SOC) experts on our managed detection and response (MDR) team — but we know some teams may want the ability to fine tune these even further. In our Q3 wrap-up, we highlighted our new detection rules management experience. This quarter, we’ve made even more strides in leveling up our capabilities around detections to help you make more informed decisions and accelerate your time to respond.

Attacker Behavior Analytics Detection Rules viewed and sorted by rule priority

• New detection rules management interface: With this new interface, you can see a priority field for each detection provided by InsightIDR with new actions available.
  • Change priority of detections and exceptions that are set to Creates Investigation as the Rule Action.
  • View and sort on priority from the main detection management screen.
  • More details on our detection rules experience can be found in our help docs, here.
• ****Customizable priorities for UBA detection rules and custom alerts:****Customers can now associate a rule priority (Critical, High, Medium, or Low) for all of their UBA and custom alert detection rules. The priority is subsequently applied to investigations created by a detection rule.
• ****A simplified way to create exceptions:**** We added a new section to detection rule details within “create exception” to better inform on which data to write exceptions against. This will show up to the 5 most recent matches associated with that said detection rule — so now, when you go to write exceptions, you have all the information you may need all within one window.

MITRE ATT&CK Matrix for detection rules

This new view maps detection rules to MITRE tactics and techniques commonly used by attackers. The view lets you see where you have coverage with Rapid7’s out-of-the-box detection rules for common attacker use cases and dig into each rule to understand the nature of that detection.

MITRE ATT&CK Matrix within Detection Rules

Investigation Management reimagined

At Rapid7, we know how limited a security analyst’s time is, so we reconfigured our Investigation Management experience to help our users improve the speed and quality of their decision-making when it comes to investigations. Here’s what you can expect:

• A revamped user interface with expandable cards displaying investigation information
• The ability to view, set, and update the priority, status, or disposition of an investigation
• Filtering by the following fields: date range, assignee, status, priority level
  New investigations interface

We also introduced MITRE-driven insights in Investigations. Now, you can click into the new MITRE ATT&CK tab of the Evidence panel in Investigation to see descriptions of each tactic, technique, and sub-technique curated by MITRE and link out to attack.mitre.org for more information.

MITRE ATT&CK tab within Investigations Evidence panel

Rapid7’s ongoing emergent threat response to Log4Shell

Like the rest of the security community, we have been internally responding to the critical remote code execution vulnerability in Apache’s Log4j Java library (a.k.a. Log4Shell).

Through continuous collaboration and ongoing threat landscape monitoring, our Incident Response, Threat Intelligence and Detection Engineering, and MDR teams are working together to provide product coverage for the latest techniques being used by malicious actors. You can see updates on our InsightIDR and MDR detection coverage here and in-product.

Stay up to date with the latest on Log4Shell:

• View Log4Shell AttackerKB for our analysis
• Check out The Everyperson’s Guide to Log4Shell
• Head to our Log4Shell Resource Center for up-to-date information for customers

A continually expanding library of pre-built dashboards

InsightIDR’s Dashboard Library has a growing repository of pre-built dashboards to save you time and eliminate the need for you to build them from scratch. In Q4, we released 15 new pre-built dashboards covering:

• Compliance (PCI, HIPAA, ISO)
• General Security (Firewall, Asset Authentication)
• Security Tools (Okta, Palo Alto, Crowdstrike)
• Enhanced Network Traffic Analysis
• Cloud Security
  Dashboard Library in InsightIDR

Additional dashboard and reporting updates

• ****Updates to dashboard filtering:**** Dashboard Filtering gives users the ability to further query LEQL statements and the data across all the cards in their dashboard. Customers can now populate the dashboard filter with Saved Queries from Log Search, as well as save a filter to a dashboard, eliminating the need to rebuild it every session.
• ****Chart captions:**** We’ve added the ability for users to write plain text captions on charts to provide extra context about a visualization.
• ****Multi-group-by queries and drill-in functionality:**** We’ve enabled Multi-group-by queries (already being used in Log search) so that customers can leverage these in their dashboards and create cards with layered data that they can drill in and out of.

Updates to Log Search and Event Sources

We recently introduced Rapid7 Resource Names (RRN), which are unique identifiers added to users, assets, and accounts in log search. An RRN serves as a unique identifier for platform resources at Rapid7. This unique identifier will stay consistent with the resource regardless of any number of names/labels associated with the resource.

In log search, an “R7_context" object has been added for log sets that have an attributed user, asset, account, or local accounts. Within the “R7_context" object, you will see any applicable RRNs appended. You can utilize the RRN as a search in log search or in the global search (which will link to users and accounts or assets and endpoints pages) to assist with more reliable searches for investigation processes.

New “r7_context" Rapid7 Resource Name (RRN) data in Log Search

****Event source updates****

• ****Log Line Attribution for Palo Alto Firewall & VPN, Proofpoint TAP, Fortinet Fortigate****: When setting up an event source you now have an option to leverage information directly present in source log lines, rather than relying solely on InsightIDR’s traditional attribution engine.
• ****Cylance Protect Cloud event source****: You can configure CylancePROTECT cloud to send detection events to InsightIDR to generate virus infection and third-party alerts.
• ****InsightIDR Event Source listings available in the********Rapid7 Extensions Hub****: Easily access all InsightIDR event source related content in a centralized location.

Updates to Network Traffic Analysis capabilities

****Insight Network Sensor optimized for 10Gbs+ deployments****: We have introduced a range of performance upgrades that make high-speed traffic analysis more accessible using off-the-shelf hardware, so you’re able to gain east-west and north-south traffic visibility within physical, virtual and cloud based networks. If you want to take full advantage of these updates check out the updated sensor requirements here.

****InsightIDR Asset Page Updates****: We have introduced additional data elements and visuals to the Assets page. This delivers greater context for investigations and enables faster troubleshooting, as assets and user information is in one location. All customers have access to:

• Top IDS events triggered by asset
• Top DNS queries

For customers with Insight Network Sensors and ENTA, these additional elements are available:

• Top Applications
• Countries by Asset Location
• Top Destination IP Addresses
  

Stay tuned!

Read More

FTC to Go After Companies that Ignore Log4j

 

Description

The Federal Trade Commission (FTC) will muster its legal muscle to pursue companies and vendors that fail to protect consumer data from the risks of the Log4j vulnerabilities, it warned on Tuesday.

“The FTC intends to use its full legal authority to pursue companies that fail to take reasonable steps to protect consumer data from exposure as a result of Log4j, or similar known vulnerabilities in the future,” according to the warning.

Those companies that bungle consumer data, leaving vulnerabilities unpatched and thus opening the door to exploits and the resulting possible “loss or breach of personal information, financial loss and other irreversible harms,” are risking consequences tied to weighty laws that have resulted in fat fines, the FTC said.

It mentioned, among others, the Federal Trade Commission Act and the Gramm-Leach-Bliley Act. The FTC Act, the commission’s primary statute, enables it to seek monetary redress and other relief for conduct injurious to consumers. Gramm-Leach-Bliley requires financial institutions to safeguard sensitive data.

“ It is critical that companies and their vendors relying on Log4j act now, in order to reduce the likelihood of harm to consumers, and to avoid FTC legal action,” the FTC urged.

The FTC means it: Its warning included a reference to the complaints against Equifax, which agreed to pay $700 million to settle actions by the FTC, the Consumer Financial Protection Bureau, and all fifty states over its infamous 2017 data leak (consumers’ reaction at the time: Make it hurt more).

According to the Equifax complaint, its failure to patch a known vulnerability “irreversibly exposed the personal information of 147 million consumers.” Expect more of the same if your company fails to protect consumer data from exposure as a result of Log4Shell or whatever similar, known vulnerabilities crop up, it said.

The FTC advised companies to use guidance from the Cybersecurity and Infrastructure Security Agency (CISA) to check if they’re using Apache’s Log4j logging library, which is at the heart of the cluster of vulnerabilities known as Log4Shell.

Companies that find that they are using Log4j should do the following, CISA recommended:

• Update your Log4j software package to the most current version.
• Consult CISA guidance to mitigate this vulnerability.
• Ensure remedial steps are taken to ensure that your company’s practices do not violate the law. Failure to identify and patch instances of this software may violate the FTC Act.
• Distribute this information to any relevant third-party subsidiaries that sell products or services to consumers who may be vulnerable.

On Dec. 17, CISA issued an emergency directive mandating federal civilian departments and agencies to immediately patch their internet-facing systems for the Log4j vulnerabilities by Thursday, Dec. 23. Federal agencies were given five more days – until Dec. 28 – to report Log4Shell-affected products, including vendor and app names and versions, along with what actions have been taken – e.g. updated, mitigated, removed from agency network – to block exploitation attempts.

CISA provides a dedicated page for the Log4Shell flaws with patching information and has released a Log4j scanner to hunt down potentially vulnerable web services.

The Log4j Fire Rages Unabated

The initial flaw – CVE-2021-44228 – was discovered on Dec. 9 and came under attack within hours. As of Dec. 15, more than 1.8 million attacks, against half of all corporate networks, using at least 70 distinct malware families, had already been launched to exploit what became a trio of bugs:

1. The Log4Shell remote-code execution (RCE) bug that spawned even nastier mutations and which led to …
2. The potential for denial-of-service (DoS) in Apache’s initial patch. Plus, there was …
3. A third bug, a DoS flaw similar to Log4Shell in that it also affected the logging library. It differed in that it concerned Context Map lookups, not the Java Naming and Directory Interface (JNDI) lookups to an LDAP server involved in CVE-2021-44228: lookups that allow attackers to execute any code that’s returned in the Log4Shell vulnerability.

At this point, the Conti ransomware gang has had a full attack chain in place for weeks.

In a Monday update, Microsoft said that the end of December brought no relief: The company observed state-sponsored and cyber-criminal attackers probing systems for the Log4Shell flaw through month’s end. “Microsoft has observed attackers using many of the same inventory techniques to locate targets. Sophisticated adversaries (like nation-state actors) and commodity attackers alike have been observed taking advantage of these vulnerabilities. There is high potential for the expanded use of the vulnerabilities,” Microsoft security researchers warned.

“Exploitation attempts and testing have remained high during the last weeks of December. We have observed many existing attackers adding exploits of these vulnerabilities in their existing malware kits and tactics, from coin miners to hands-on-keyboard attacks,” the researchers said.

Hunting Down Log4j

One of the most challenging aspects of responding to the Log4j vulnerability is simply identifying the devices in an organization where Log4j is used. The word “ubiquitous” has applied since the get-go.

“Since it is a cross-platform, widely used software library, there is incredible diversity in where and how it is deployed: it can be an application package installed by itself, bundled with another application package as just another file on disk or embedded in another application with no visible artifact,” J.J. Guy, co-founder and CEO at Sevco Security, told Threatpost on Wednesday.

He added, “Even worse, it is used in everything from cloud-managed services to server applications and even fixed-function, embedded devices. That internet-connected toaster is very likely vulnerable to Log4Shell.”

We’re just in the middle of the triage phase now, Guy said, where basic tools like systems-management or software-management tools to check for the file on disk can provide initial triage.

One question: What’s the inventory of equipment that still needs to be triaged?

“For organizational leaders, such as the board, CEO, CIO or CISO, to have confidence in those triage results requires they report not only the machines that have been triaged but also how many are pending triage,” Guy remarked. “Reporting the ‘pending triage’ statistic requires a complete asset inventory, including which machines have been successfully triaged.”

He called this “one of the larger hidden challenges” in every organization’s response, given that so few have a comprehensive asset inventory, “despite the fact it has been a top requirement in every security compliance program for decades.”

Read More

Microsoft Warns of Continued Attacks Exploiting Apache Log4j Vulnerabilities

 

Description

Microsoft is warning of continuing attempts by nation-state adversaries and commodity attackers to take advantage of security vulnerabilities uncovered in the Log4j open-source logging framework to deploy malware on vulnerable systems.

“Exploitation attempts and testing have remained high during the last weeks of December,” Microsoft Threat Intelligence Center (MSTIC) said in revised guidance published earlier this week. “We have observed many existing attackers adding exploits of these vulnerabilities in their existing malware kits and tactics, from coin miners to hands-on-keyboard attacks.”

Publicly disclosed by the Apache Software Foundation on December 10, 2021, the remote code execution (RCE) vulnerability in Apache Log4j 2, aka Log4Shell, has emerged as a new attack vector for widespread exploitation by a variety of threat actors.

In the subsequent weeks, four more weaknesses in the utility have come to light — CVE-2021-45046, CVE-2021-45105, CVE-2021-4104, and CVE-2021-44832 — providing opportunistic bad actors with persistent control over the compromised machines and mount an evolving array of attacks ranging from cryptocurrency miners to ransomware.

Even as the mass scanning attempts are showing no signs of letting up, efforts are underway to evade string-matching detections by obfuscating the malicious HTTP requests orchestrated to generate a web request log using Log4j that leverages JNDI to perform a request to the attacker-controlled site.

In addition, Microsoft said it observed “rapid uptake of the vulnerability into existing botnets like Mirai, existing campaigns previously targeting vulnerable Elasticsearch systems to deploy cryptocurrency miners, and activity deploying the Tsunami backdoor to Linux systems.”

On top of that, the Log4Shell vulnerability has also been put to use to drop additional remote access toolkits and reverse shells such as Meterpreter, Bladabindi (aka NjRAT), and HabitsRAT.

“At this juncture, customers should assume broad availability of exploit code and scanning capabilities to be a real and present danger to their environments,” MSTIC noted. “Due to the many software and services that are impacted and given the pace of updates, this is expected to have a long tail for remediation, requiring ongoing, sustainable vigilance.”

The development also comes as the U.S. Federal Trade Commission (FTC) issued a warning that it “intends to use its full legal authority to pursue companies that fail to take reasonable steps to protect consumer data from exposure as a result of Log4j, or similar known vulnerabilities in the future.”

Read More

Microsoft Sees Rampant Log4j Exploit Attempts, Testing

 

Description

No surprise here: The holidays bought no Log4Shell relief.

Threat actors vigorously launched exploit attempts and testing during the last weeks of December, Microsoft said on Monday, in the latest update to its landing page and guidance around the flaws in Apache’s Log4j logging library.

“We have observed many existing attackers adding exploits of these vulnerabilities in their existing malware kits and tactics, from coin miners to hands-on-keyboard attacks,” according to Microsoft.

This comes on the heels of news that relentless Log4Shell attacks have come from nation-state actors that are both testing and have already implemented the exploit: As of Dec. 15, more than 1.8 million attacks, against half of all corporate networks, using at least 70 distinct malware families, had already been launched to exploit the bugs.

What is Log4Shell?

The remote code execution (RCE) vulnerabilities in Apache Log4j 2 – CVE-2021-44228, CVE-2021-45046, CVE-2021-44832 – are collectively referred to as Log4Shell. Within hours of the initial flaw’s public disclosure on Dec. 10, attackers were scanning for vulnerable servers and unleashing quickly evolving attacks to drop coin-miners, Cobalt Strike, the Orcus remote access trojan (RAT), reverse bash shells for future attacks, Mirai and other botnets, and backdoors.

The new attack vector presented by Log4Shell is vast, severe and has ample potential for widespread exploitation. The flaw, which is uber-easy to exploit, is resident in the ubiquitous Java logging library Apache Log4j and could allow unauthenticated RCE and complete server takeover.

Within three days of the flaw’s disclosure, it was spitting out mutations. Within 10 days, the notorious Conti ransomware gang had created a holistic Log4Shell attack chain. As of last week, Dec. 30, the advanced persistent threat (APT) Aquatic Panda was targeting universities with Log4Shell exploit tools in an attempt to steal industrial intelligence and military secrets.

Obfuscated HTTP Requests

Most recently, Microsoft has observed attackers obfuscating the HTTP requests made against targeted systems. Those requests generate a log using Log4j 2 that leverages Java Naming and Directory Interface (JNDI) to perform a request to the attacker-controlled site. The vulnerability then causes the exploited process to reach out to the site and execute the payload.

Microsoft has observed many attacks in which the attacker-owned parameter is a DNS logging system, intended to log a request to the site to fingerprint the vulnerable systems. The crafted string that enables Log4Shell exploitation contains “jndi,” following by the protocol – such as “ldap,” “ldaps” “rmi,” “dns,” “iiop,” or “http” – and then the attacker domain.

But to evade detection, attackers are mixing up the request patterns: For example, Microsoft has seen exploit code written that runs a lower or upper command within the exploitation string. Even more complicated obfuscation attempts are being made to try to bypass string-matching detections, such as that shown in the string sample below:

Minecraft Servers Still Being Exploited

Exploitation continues on non-Microsoft-hosted Minecraft servers, the company said: as in, the same type of servers where Log4j was first discovered.

Microsoft confirmed public reports of Khonsari ransomware being delivered as payload post-exploitation, as Bitdefender has detailed. Microsoft Defender antivirus data has shown a small number of cases being launched from compromised Minecraft clients connected to modified Minecraft servers running a vulnerable version of Log4j 2 via the use of a third-party Minecraft mods loader, the company said.

“In these cases, an adversary sends a malicious in-game message to a vulnerable Minecraft server, which exploits CVE-2021-44228 to retrieve and execute an attacker-hosted payload on both the server and on connected vulnerable clients,” Microsoft said. “We observed exploitation leading to a malicious Java class file that is the Khonsari ransomware, which is then executed in the context of javaw.exe to ransom the device.”

While Minecraft isn’t commonly installed in enterprise networks, Microsoft has nonetheless also observed PowerShell-based reverse shells being dropped to Minecraft client systems via the same malicious message technique, enabling an actor to fully take over a compromised system, which they then use to run Mimikatz to steal credentials.

“These techniques are typically associated with enterprise compromises with the intent of lateral movement,” Microsoft said, meaning that the goal in targeting of Minecraft users, who tend to be children, seems unclear. It’s early yet in this campaign: There hasn’t yet been detectible follow-on activity yet, “indicating that the attacker may be gathering access for later use.”

Microsoft urged Minecraft customers running their own servers to deploy the latest Minecraft server update and for players to exercise caution by only connecting to trusted Minecraft servers.

Nation-State Activity

Microsoft’s Threat Intelligence Center (MSTIC) has also observed the CVE-2021-44228 flaw being used by multiple tracked nation-state activity groups originating from China, Iran, North Korea and Turkey.

The actors are experimenting during development, integrating the vulnerabilities to in-the-wild payload deployment, and sending exploitations against targets.

One example: MSTIC has observed the ransomware-wielding, Iranian Phosphorus actor – aka Charming Kitten, TA453, APT35, Ajax Security Team, NewsBeef or Newscaster, et al. – acquiring and making modifications of the Log4j exploit.

“We assess that Phosphorus has operationalized these modifications,” Microsoft observed.

MSTIC has also seen the China-linked Hafnium group using the vulnerability to attack virtualization infrastructure in order to extend the group’s typical targeting. “In these attacks, Hafnium-associated systems were observed using a DNS service typically associated with testing activity to fingerprint systems,” researchers noted.

Microsoft’s “I’m-a-broken-record” advice: Update affected products and services, and apply security patches ASAP.

“With nation-state actors testing and implementing the exploit and known ransomware-associated access brokers using it, we highly recommend applying security patches and updating affected products and services as soon as possible,” Microsoft said.

RAT Infestation

Microsoft is also seeing additional remote-access toolkits and reverse shells being dropped via exploitation of CVE-2021-44228, which is malware that actors use for hands-on-keyboard attacks. Besides the Cobalt Strike beacons and PowerShell reverse shells seen in earlier reports, the company has also seen Meterpreter, Bladabindi and HabitsRAT.

“Follow-on activities from these shells have not been observed at this time, but these tools have the ability to steal passwords and move laterally,” Microsoft noted.

The activity is coming from small-scale, possibly more targeted attacks (possibly related to testing campaigns), the software giant said. Also, researchers have observed the addition of CVE-2021-44428 to existing campaigns that were exploiting vulnerabilities to drop remote access tools. Microsoft said that the HabitsRAT campaign overlapped with infrastructure used in prior campaigns.

Other Log4Shell Developments

Microsoft has also seen:

Multiple ransomware access brokers using the vulnerability to gain initial access to target networks – access that they sell to ransomware-as-a-service (RaaS) affiliates. “We have observed these groups attempting exploitation on both Linux and Windows systems, which may lead to an increase in human-operated ransomware impact on both of these operating system platforms,” Microsoft said.

Mass scanning by both attackers and security researchers.The vulnerability has rapidly gotten sucked up into existing botnets like Mirai, existing campaigns previously targeting vulnerable Elasticsearch systems to deploy cryptocurrency miners, and activity deploying the Tsunami backdoor to Linux systems. “Many of these campaigns are running concurrent scanning and exploitation activities for both Windows and Linux systems, using Base64 commands included in the JDNI:ldap:// request to launch bash commands on Linux and PowerShell on Windows,” the company said.

No big spikes in ransomware attacks. True, ransomware has been delivered via modified Minecraft clients, but so far it’s been only a small number of cases. That could change, given that access brokers associated with RaaS affiliates are folding the vulnerability into their initial-access toolkits. But Microsoft is also seeing older ransomware payloads in limited use by security researchers and a small number of attackers. “In some instances, they appear to be experimenting with deployments via scanning and modified Minecraft servers,” Microsoft said. “As part of these experiments, some ransomware payloads seem to have been deployed to systems that were previously compromised and were originally dropping coin-miner payloads.”

Webtoos Malware. Webtoos, a malware with distributed denial-of-service (DDoS) capabilities and persistence mechanisms that could allow an attacker to wreak yet more havoc, is also being deployed via the Log4Shell vulnerability. “Attackers’ use of this malware or intent is not known at this time, but the campaign and infrastructure have been in use and have been targeting both Linux and Windows systems prior to this vulnerability,” Microsoft said.

Microsoft’s post has extensive advice on attack vectors and observed activity, finding and remediating vulnerable apps and systems, detecting and responding to exploitation attempts and other related attacker activity, and indicators of compromise (IoCs).

This Is Just the Start

As if all that weren’t enough, it’s all likely going to get worse, Microsoft said. Just like Log4j is tucked away into nooks and crannies, so too are exploits going to get added to yet more attacker toolkits: “The majority of attacks we have observed so far have been mainly mass scanning, coin-mining, establishing remote shells and red-team activity, but it’s highly likely that attackers will continue adding exploits for these vulnerabilities to their toolkits,” Microsoft said.

How Do You Even Know Where Log4J Is Lurking?

A massive part of the Log4Shell nightmare is the fact that it’s not always obvious which software is using a vulnerable version of the Log4j library.

While Microsoft has laid out several methods for detecting active exploit attempts using Log4j, identifying the vulnerable version before an attack would be “ideal,” according to Ray Kelly, a fellow at NTT Application Security.

“This will be a continuing battle for both consumers and vendors going forward into 2022 in what will need to be a two-pronged approach,” Kelly told Threatpost. “Security vendors have been quick on the response for consumers by adding log4j rules that enable DAST [dynamic application security scanning] scanners to detect if a website can be exploited with a malicious log4j web request against a company’s web server. At the same time, vendors must ensure that they are not shipping software with the vulnerable version using tools such as SCA [service component architecture].”

Asking What to Do? It’s a Little Late for That

Jake Williams, co-founder and CTO at BreachQuest, echoed Microsoft’s assertion that this vulnerability will have an extremely long tail for exploitation, considering that many organizations don’t even realize they’re running vulnerable software.

“Unfortunately (and nobody wants to hear this), there’s nothing left to say about remediating log4j that hasn’t already been said hundreds of times,” Williams told Threatpost. “Any organization asking today what they need to do regarding log4j almost certainly has an incident on their hands. Every organization with a security team knows what needs to be done to hunt down log4j, they just need the resources and political backing to actually get it done. Being exploited through an internet-facing system running vulnerable log4j at this point is a leadership failure, not a technical one.”

Password****Reset: ****On-Demand Event: Fortify 2022 with a password-security strategy built for today’s threats. This Threatpost Security Roundtable, built for infosec professionals, centers on enterprise credential management, the new password basics and mitigating post-credential breaches. Join Darren James, with Specops Software and Roger Grimes, defense evangelist at KnowBe4 and Threatpost host Becky Bracken.Register & stream this FREE session today – sponsored by Specops Software.

Read More

5 Security Projects That Are Giving Back

 

Description

Editor’s note:We had planned to publish our Hacky Holidays blog series throughout December 2021 – but then Log4Shell happened, and we dropped everything to focus on this major vulnerability that impacted the entire cybersecurity community worldwide. Now that it’s 2022, we’re feeling in need of some holiday cheer, and we hope you’re still in the spirit of the season, too. Throughout January, we’ll be publishing Hacky Holidays content (with a few tweaks, of course) to give the new year a festive start. So, grab an eggnog latte, line up the carols on Spotify, and let’s pick up where we left off.

While it’s always nice to receive gifts, the holiday season is more about giving – whether you’re buying something nice for the people you love or giving back to the community to help ensure others enjoy the holidays as much as you do.

Giving back is exactly what we’ll be focusing on in today’s Hacky Holidays post, as it’s a theme that truly resonates with those in the security industry. From white-hat hackers to those volunteering their time to make the internet a safer, more inclusive space, we’ve highlighted a few security-related projects that exemplify the spirit of giving back.

1. The Innocent Lives Foundation

The Innocent Lives Foundation aims to identify child predators and help bring them to justice. They do this by leveraging the combined power of the information security community to create tools that unmask anonymous child predators online. Then, using the data from Open Source Intelligence and cutting-edge techniques, they build a path to capturing evidence and then pass on those details to law enforcement for them to recreate.

The Innocent Lives Foundation was first started by Chris Hadnagy, who joined us on an episode of our Security Nation podcast back in 2020. He worked on a few cases at Social-Engineer, LLC, that tracked and captured predators who trafficked and exploited children. When he saw the impact these crimes had on innocent people, he knew he had to do something about it. As a leader in the information security community, he chose to rally a group of security experts and professionals in the social engineering field to address these problems and prevent crimes against future victims.

The foundation is serving endangered children and building a world in which all children can live innocent lives. It’s difficult, emotionally taxing work, but it’s making the world a better place, and it’s the perfect example of giving back.

If you’d like to donate to the cause — it can cost up to $10,000 to produce one file to send to law enforcement, so donations are needed and welcomed — you can do so here. Aside from donating, there are numerous other ways to get involved, including reporting a case, sharing support online, or even volunteering your security skills when applications are opened.

2. No More Ransom

Today, ransomware is rampant. This fact won’t surprise anyone working in the security industry, but many normal users around the world don’t know what ransomware is, how to defend against it, and what to do if they fall victim to a scam. That’s where No More Ransom comes into play.

No More Ransom is an initiative by the National High Tech Crime Unit of the Netherlands’ police, Europol’s European Cybercrime Centre, Kaspersky, and McAfee with a simple mission: to help victims of ransomware retrieve their encrypted data without paying criminals a single dime in the process.

The initiative aims to achieve this mission in two ways:

1. By compiling a repository of keys and applications that can decrypt data locked by different types of ransomware
2. By spreading awareness about ransomware and educating the world about prevention methods they can employ in their daily lives

While it’s not always possible to regain access to files encrypted by or systems locked by ransomware, No More Ransom has helped many do exactly that with its repository. And by sharing simple, easy-to-follow cybersecurity advice, the initiative is creating a better informed world of users who understand how to prevent falling victim to ransomware in the first place.

In the 5 years of since its creation, the No More Ransom initiative has:

• Built a library of 121 free tools
• Been able to decrypt 151 ransomware families
• Seen more than 6 million downloads of its tools
• Prevented $900 million in criminal profit

If you’d like to do your part, the No More Ransom project is always looking for new partners to spread their messaging, so if your organization wants to be more security-minded and give back to the security community in general, consider joining the list of many partners. If you ever fall victim to ransomware, you can also report the crime, which will help identify new types of ransomware and aid future prevention.

3. CIAS Gaming

Established by the University of Texas at San Antonio, the Center for Infrastructure Assurance and Security (CIAS) conducts research into effective ways to engage students with cybersecurity principles through educational gaming — and as part of their work, they’re making cybersecurity relatable, fun, and engaging for kids.

The CIAS Gaming program targets 4 demographics: elementary school, middle school, high school, and colleges and universities. Their mission is to deliver quality research, training, competition, and exercise programs to advance community and organizational cybersecurity capabilities and collaboration.

Currently, the CIAS K-12 Program consists of a few educational tools. These include:

• A collectible card game and electronic download called Cyber Threat Defender
• A multiplayer card game for students in third through fifth grade called Cyber Threat Protector
• A card game for K-2 players with simple design and reinforced concepts called Cyber Threat Guardian
• An electronic game that teaches techniques for encoding and decoding ciphers to hide or discover information called Project Cipher
• A testing tool and platform that gives educators a way to create quizzes and introduce students to cybersecurity principles called the Pyramid of Knowledge
• Interactive activities, like activity sheets and games, introduced to kids by the CyBear cybersecurity mascots

CIAS Gaming is shaping the future of cybersecurity by training the next generation in cybersecurity best practices. You can access and download these tools and games via the links above, or reach out directly to CIAS to learn more about taking part in their competitions or trainings.

4. The Alliance for Securing Democracy

The Alliance for Securing Democracy (ASD) is a nonpartisan initiative housed within the German Marshall Fund of the United States that aims to combat autocratic efforts to undermine and interfere in democratic institutions around the world. The ASD contributes research and analysis on how a range of tools, from cyberattacks and disinformation to support for extremism, are being used to weaken democracies. It also provides public dashboards to expose the effects of online influence networks and the themes being promoted by foreign powers to threaten democratic institutions.

The ASD is independently funded by more than 175 private individuals and small family foundations across the political spectrum. Its team brings together a diverse staff with expertise across industries, including technology and cybersecurity, to provide research, policy recommendations, and even analysis of key issues and threats. It also has a technical advisory committee that features experts on disinformation, cybersecurity, illicit finance, and more.

The ASD has conducted a significant amount of work in the area of cybersecurity. It also has compiled a toolbox to spread awareness on various techniques being used by malign actors. Such tools include:

• The Authoritarian Interference Tracker, which exposes Russia and China’s foreign interference activities
• The Information Operations Archive, which houses data points from known Information Operations
• The Hamilton 2.0 Dashboard, which reveals autocracies’ state-backed messaging

In a more globalized and digitalized world, the work ASD is doing to protect the strength of free and open societies by shining a light on autocratic tactics, closing vulnerabilities in democratic systems, and imposing costs on those who undermine our institutions is more important than ever. You can reach them at info@securingdemocracy.org or donate to the cause.

5. Code for Social Good

Code for Social Good is a nonprofit organization that partners with other nonprofit companies to provide the technical help they need to achieve their missions for no cost. It’s all about volunteering to promote social good: Code for Social Good has built and fostered a volunteer community that promotes welfare by supporting nonprofits in need. And that global network consists of professionals from across the tech industry, including technical writers, coders, programmers, and more.

Whether you code for fun, experience, social good, or to make a better world, volunteering at Code for Social Good is a great way to give back. Anyone can sign up as a volunteer, and then, you can browse their list of projects. If you find one applicable to your skills, you can apply and wait for contact from the nonprofit. Nonprofits that need help can also post projects on the site and find volunteers to assist them.

As of this writing, Code for Social Good has 138 projects posted across 122 organizations based in 87 countries. The current volunteer community consists of 2,595 volunteers, and they’re always looking for more help. If you have some extra time, why not take a look and see if you can give back by volunteering your technical skills to a nonprofit in need.

Giving back is an important theme of the holidays and one that’s integral to the cybersecurity community. By giving back to the industry, we can encourage a healthy, flourishing practice that spreads awareness, leading to a better, safer, and brighter tomorrow.

If you’re looking for ways to give back, hopefully these examples inspire you to action. If you’d like to stay in the holiday spirit, check out the rest of our Hacky Holidays specials.

NEVER MISS A BLOG

Read More

McMenamins Data Breach Affects 12 Years of Employee Info

 

Description

A ransomware attack on the McMenamins dining and hospitality empire in the Pacific Northwest came along with a data breach covering 12 years of employee data, the organization has confirmed.

The Dec. 12 incident – which some have attributed to the Conti gang – forced McMenamins to shut down various operations, though locations can still receive customers. McMenamins is known for saving and restoring historic buildings throughout Oregon and Washington state and for giving them new lives as eclectic pubs, restaurants, breweries, hotels, movie theaters, concert venues, spas and more. In fact, 20 of its locations are on the National Register of Historic Places.

This week, McMenamins confirmed that the cyberattackers made off with internal employee data for those working for the company between the dates of Jan. 1, 1998 and June 30, 2010. The affected data is a bouillabaisse of classic HR fare: names, addresses, telephone numbers, email addresses, dates of birth, race, ethnicity, gender, disability status, medical notes, performance and disciplinary notes, Social Security numbers, health insurance plan elections, income amounts, and retirement contribution amounts.

The data could be sold and/or used for phishing attacks and other social-engineering efforts, identity theft and more.

“It’s possible that the thieves accessed files containing direct-deposit bank account information as well, but McMenamins does not have a clear indication they did so,” the company said in a Dec. 30 notice.

One ray of promise: No customer data was heisted, the company said.

“We’re devastated our people need to do so, but we’re urging them to vigilantly monitor their accounts and healthcare information for anything unusual,” said Brian McMenamin, one of the brothers who own the business, in a press statement. “They should immediately notify their financial institutions or health providers if they see anything out of sort. They should sign up immediately for free monitoring and identity-theft protection. All the information is on our website, and we encourage them to call with any questions.”

McMenamins said that it is offering past and current employees identity and credit-protection services, as well as a dedicated call center to answer questions about the attack. Letters have gone out to notify all affected individuals as well.

Still Not Recovered from December Ransomware Attack

In the wake of the attack, the company was forced to shut down its IT systems, credit-card point-of-sale systems and corporate email to prevent the further spread of the attack. Three weeks later, the company’s operations are still not remediated, it said, including its central phone system, email, credit-card processing, hotel-reservation system and gift-card processing – core functions for a hospitality group.

For now, the company is asking people to delay their hotel bookings or to call properties directly, and it’s using the third-party Dinerware point-of-sale for credit cards.

“It is unknown when the issue will be resolved and systems back up and running,” the organization said. “Given the impacts to the company’s email system, email responses are delayed.”

Brian McMenamin said the breach “is especially disheartening” given its timing after the “strain and hardship” McMenamins’ employees have gone through over the past two years during the pandemic.

McMenamins has reported the incident to the FBI and is also working with a cybersecurity firm to identify the source and full scope of the attack, the company said.

Some sources have attributed the attack to the Russian-speaking Conti gang – a group that Palo Alto Networks has called “one of the most ruthless” and sophisticated ransomware groups out there. Conti is known to ask for unreasonable ransom amounts, such as the $40 million ransom demand it made of Broward County Public Schools in Fort Lauderdale, Fla., earlier this year. It also has a history of hitting organizations while they’re down, as seen in a May attack on the Irish health service.

It also recently tinkered with its code (and its personnel recruiting) to juice its ability to find and fully destroy backups that victims may otherwise use to restore operations in the wake of a ransomware hit. And, in late December, Conti became one of the first professional gangs to claim a full Log4Shell exploit chain.

Read More