Healthcare Cybersecurity

FBI and CISA Issue Joint Warning About Vishing Campaign Targeting Teleworkers

Posted by HIPAA Journal

An ongoing voice phishing (vishing) campaign is being conducted targeting remote workers from multiple industry sectors. The threat actors impersonate a trusted entity and use social engineering techniques get targets to disclose their corporate Virtual Private Network (VPN) credentials.

The Federal Bureau of Investigation (FBI) and the DHS Cybersecurity and infrastructure Security Agency (CISA) have issued a joint advisory about the campaign, which has been running since mid-July.

The COVID-19 pandemic forced many employers to allow their entire workforce to work from home and connect to the corporate network using VPNs. If those credentials are obtained by cybercriminals, they can be used to access the corporate network.

The threat group first purchases and registers domains that are used to host phishing pages that spoof the targeted company’s internal VPN login page and SSL certificates are obtained for the domains to make them appear authentic. Several naming schemes are used for the domains to make them appear legitimate, such as [company]-support, support-[company], and employee-[company].

The threat group then gathers information about company employees by scraping social media profiles and compiles dossiers on specific employees. The types of information collected include personal information such as an employee’s name, address, personal phone number, job title, and length of time at the company. That information is then used to gain the trust of the targeted employee.

Employees are then called from a voice-over-IP (VOIP) number. Initially the VOIP number was anonymous, but later in the campaign the attackers started spoofing the number to make it appear that the call was coming from a company office or another employee in the firm. Employees are then told they will receive a link that they need to click to login to a new VPN system. They are also told that they will need to respond to any 2-factor authentication and one-time password communications sent to their phone.

The attackers capture the login information as it is entered into their fraudulent website and use it to login to the correct VPN page of the company. They then capture and use the 2FA code or one-time password when the employee responds to the SMS message.

The attackers have also used SIM-swap to bypass the 2FA/OTP step, using information gathered about the employee to convince their mobile telephone provider to port their phone number to the attacker’s SIM. This ensures any 2FA code is sent directly to the attacker. The threat actors use the credentials to access the company network to steal sensitive data to use in other attacks. The FBI/CISA say the end goal is to monetize the VPN access.

The FBI/CISA recommend organizations restrict VPN connections to managed devices using mechanisms such as hardware checks or installed certificates, to restrict the hours that VPNs can be used to access the corporate network, to use domain monitoring tools to monitor web applications for unauthorized access and anomalous activities.

A formal authentication procedure should also be introduced for employee-to-employee communications over the public telephone network where a second factor is required to authenticate the phone call prior to the disclosure of any sensitive information.

Organizations should also monitor authorized user access and usage to identify anomalous activities and employees should be notified about the scam and instructed to report any suspicious calls to their security team.

The post FBI and CISA Issue Joint Warning About Vishing Campaign Targeting Teleworkers appeared first on HIPAA Journal.

Millions of Devices Affected by Vulnerability in Thales Wireless IoT Modules

Posted by HIPAA Journal

A vulnerability in components used in millions of IoT devices could be exploited by hackers and used to steal sensitive information and gain control of vulnerable devices, which could then be used in attacks on internal networks. Thales components are used by more than 30,000 companies, whose products are used across a broad range of industry sectors including energy, telecommunications, and healthcare.

The flaw exists in the Cinterion EHS8 M2M module, along with several other products in the same line (BGS5, EHS5/6/8, PDS5/6/8, ELS61, ELS81, PLS62). The embedded modules provide processing power and allow devices to send and receive data over wireless mobile connections. The module is also used as a digital secure repository for sensitive information such as passwords, credentials and operational code. The flaw would allow an attacker to gain access to the contents of that repository.

X-Force Red researchers discovered a method for bypassing security measures protecting code and files in the EHS8 module. “[The modules] store and run Java code, often containing confidential information like passwords, encryption keys and certificates,” said Adam Laurie, of IBM’s X-Force Threat Intelligence team.

“This vulnerability could enable attackers to compromise millions of devices and access the networks or VPNs supporting those devices by pivoting onto the provider’s backend network. In turn, intellectual property, credentials, passwords and encryption keys could all be readily available to an attacker,” explained the researchers in a recent blog post. “Using information stolen from the modules, malicious actors can potentially control a device or gain access to the central control network to conduct widespread attacks – even remotely via 3G in some cases.”

In medical devices, the flaw could be exploited to alter readings from patient monitoring devices, either to generate false alerts or hide critical changes in a patient’s vital signs. In the case of a drug pump, changes could be made to deliver an overdose or stop a dose of critical medication from being administered.

The researchers also point out that the flaw could be exploited in smart meters used by energy companies to falsely report energy usage. This would result in increases or decreases in bills, but if sufficient numbers of devices were compromised and controlled by an attacker, it could cause damage to the grid and result in blackouts.

The vulnerability, tracked as CVE-2020-15858, was identified in September 2019 and Thales was immediately notified. Thales has been working closely with IBM X Force Red team to develop, test, and distribute a patch. The patch was released in February 2020 and Thales has been working hard to make sure its customers are aware of the patch and the need to apply that patch promptly.

It is taking some time for the patches to be applied by device manufacturers. The patching process is considerably slower for devices used in highly regulated industry sectors. For instance, medical devices may will require recertification after patching, which is a time-incentive process.

Addressing the vulnerability is largely down to device manufacturers, who must make patching a priority. IBM X Force Red says that process has been ongoing for 6 months, but there are still many devices that remain vulnerable. Patches could be applied via a USB device plugged directly into the vulnerable device using the management console or via an over-the-air update. The latter would be preferable, but that would depend on whether the device is accessible over the Internet.

The post Millions of Devices Affected by Vulnerability in Thales Wireless IoT Modules appeared first on HIPAA Journal.

New FritzFrog P2P Botnet Targets SSH Servers of Banks, Education, and Medical Centers

Posted by HIPAA Journal

A new peer-to-peer (P2) botnet has been discovered that is targeting SSH servers found in IoT devices and routers which accept connections from remote computers. The botnet, named FritzFrog, spreads like a computer worm by brute forcing credentials.

The botnet has been analyzed by security researchers at Guardicore Labs and was found to have successfully breached more than 500 servers, with that number growing rapidly. FritzFrog is modular, multi-threaded, and fileless, and leaves no trace on the machines it infects. FritzFrog assembles and executes malicious payloads entirely in the memory, making infections hard to detect.

When a machine is infected, a backdoor is created in the form of an SSH public key, which provides the attackers with persistent access to the device. Additional payloads can then be downloaded, such as a cryptocurrency miner. Once a machine is compromised, the self-replicating process starts to execute the malware throughout the host server. The machine is added to the P2P network, can receive and execute commands sent from the P2P network, and is used to propagate the malware to new SSH servers. The botnet has been active since at least January 2020 and has been used to target government, healthcare, education, and the finance sectors.

“Nodes in the FritzFrog network keep in close contact with each other. They constantly ping each other to verify connectivity, exchange peers and targets and keep each other synced,” explained the researchers. “The nodes participate in a clever vote-casting process, which appears to affect the distribution of brute-force targets across the network. Guardicore Labs observed that targets are evenly distributed, such that no two nodes in the network attempt to “crack” the same target machine.”

In contrast to other forms of botnet, FritzFrog has greater resiliency, as control of the botnet is decentralized among different nodes, so there is no single command and control (C2) server, which means there can be no single point of failure. According to Guardicore Labs, FritzFrog has been written in Golang from scratch, with the P2P protocol completely proprietary, with almost everything about the botnet unique and not shared with other P2P botnets.

To analyze how FritzFrog worked and to explore its capabilities, Guardicore Labs’ researchers developed an interceptor in Golang which allowed them to participate in the malware’s key-exchange process and receive and send commands. “This program, which we named frogger, allowed us to investigate the nature and scope of the network. Using frogger, we were also able to join the network by ‘injecting’ our own nodes and participating in the ongoing P2P traffic.” Via frogger, the researchers determined that FritzFrog had succeeded in brute-forcing millions of SSH IP addresses at medical centers, banks, educational institutions, government organizations, and telecom companies.

The malware communicates over port 1234, but not directly. Traffic over port 1234 is easy to identify, so the malware uses a netcat utility program, which is usually used to monitor network traffic. “Any command sent over SSH will be used as netcat’s input, thus transmitted to the malware,” explained the researchers. FritzFrog also communicates over an encrypted channel and is capable of executing over 30 commands, which include creating a backdoor, connecting to other infected nodes and servers in the FritzFrog network, and monitoring resources such as CPU use.

While the botnet is currently being used to plant cryptocurrency mining malware (XMRig) on victims’ devices to mine Monero, the botnet could easily be repurposed to deliver other forms of malware and could be used for several other purposes. Ophir Harpaz, security researcher at Guardicore Labs, does not believe cryptocurrency mining is the main purpose of the botnet, due to the amount of code dedicated to mining Monero. Harpaz believes it is access to organizations’ networks which is the main aim, which can be extremely valuable. Access to breached servers could be sold or used in much more profitable attacks.

It is unclear who created the botnet or where they are located. It has spread globally, but the geographic origin of the initial attacks is not known. FritzFrog is also under active development, with the researchers identifying more than 20 versions of the FritzFrog binary.

The botnet relies on network security solutions that enforce traffic only by port and protocol, so process-based segmentation rules are required. Infection takes advantage of weak passwords that are susceptible to brute force attempts, so it is important for strong passwords to be set and to use public key authentication. The botnet targets IoT devices and routers with exposed SSH keys, so organizations can protect themselves by changing their SSH port or disabling access to SSH when the service is not in use. The researchers also point out that “it is crucial to remove FritzFrog’s public key from the authorized_keys file, preventing the attackers from accessing the machine.”

Guardicore Labs has published a script on GitHub that can be run to identify FritzFrog infections, along with known IoCs.

The post New FritzFrog P2P Botnet Targets SSH Servers of Banks, Education, and Medical Centers appeared first on HIPAA Journal.

Three Vulnerabilities Identified in Philips SureSigns Vital Signs Monitors

Posted by HIPAA Journal

Three low- to medium-severity vulnerabilities have been identified in Philips SureSigns VS4 vital signs monitors. If exploited, an attacker could gain access to administrative controls and system configurations and alter settings to send sensitive patient data to a remote destination.

The vulnerabilities were identified by the Cleveland Clinic, which reported the flaws to Philips. Philips is unaware of any public exploits for the vulnerabilities and no reports have been received to date to indicate any of the vulnerabilities have been exploited.

The flaws have been categorized as improper input validation (CWE-20), Improper access control (CWE-284), and improper authentication (CWE-287).

Philips SureSigns VS4 receives input or data, but there is a lack of input validation controls to check the input has the properties to allow the data to be processed safely and correctly. This vulnerability is tracked as CVE-2020-16237 and has been assigned a CVSS V3 base score of 2.1 out of 10.

When a user claims to have a given identity, there are insufficient checks performed to prove that the identity of the individual is correct during authentication. This vulnerability is tracked as CVE-2020-16239 and has been assigned a CVSS V3 base score of 4.9 out of 10.

The highest severity flaw is due to insufficient access controls, which do not restrict, or incorrectly restrict, access to a resource from an unauthorized individual. Exploitation of the vulnerability could allow access to be gained to administrative controls and system configurations. This flaw is tracked as CVE-2020-16241 and has been assigned a CVSS V3 base score of 6.3 out of 10.

A security advisory about the flaws has now been released under Philips’ Coordinated Vulnerability Disclosure Policy, and mitigations have been suggested to reduce the potential for exploitation.

Philips recommends replacing Philips SureSigns VS4 devices with a newer technology. In the meantime, customers have been advised to change all system passwords on their devices and to use unique passwords for each device and to physically secure the devices when not in use.

The post Three Vulnerabilities Identified in Philips SureSigns Vital Signs Monitors appeared first on HIPAA Journal.

Healthcare Data Leaks on GitHub: Credentials, Corporate Data and the PHI of 150,000+ Patients Exposed

Posted by HIPAA Journal

A new report has revealed the personal and protected health information of patients and other sensitive data are being exposed online without the knowledge of covered entities and business associates through public GitHub repositories.

Jelle Ursem, a security researcher from the Netherlands, discovered at least 9 entities in the United States – including HIPAA-covered entities and business associates – have been leaking sensitive data via GitHub. The 9 leaks – which involve between 150,000 and 200,000 patient records – may just be the tip of the iceberg. The search for exposed data was halted to ensure the entities concerned could be contacted and to produce the report to highlight the risks to the healthcare community.

Even if your organization does not use GitHub, that does not necessarily mean that you will not be affected. The actions of a single employee or third-party contracted developer may have opened the door and allowed unauthorized individuals to gain access to sensitive data.

Exposed PII and PHI in Public GitHub Repositories

Jelle Ursem is an ethical security researcher who has previously identified many data leaks on GitHub, including by Fortune 500 firms, publicly traded companies, and government organizations. Ursem decided to conduct a search to find out if any medical data had been leaked on GitHub. It took just 10 minutes to confirm that it had, but it soon became clear that this was far from an isolated case.

Ursem conducted searches such as “companyname password” and “medicaid password FTP” and discovered several hard-coded usernames and passwords could be found in code uploaded to GitHub. Those usernames and passwords allowed him to login to Microsoft Office 365 and Google G Suite accounts and gain access to a wide range of sensitive information such as user data, contracts, agendas, internal documents, team chats, and the protected health information of patients.

“GitHub search is the most dangerous hacking tool out there,” said Ursem. Why go to the trouble of hacking a company when it is leaking data that can be found with a simple search on GitHub?

Ursem attempted to make contact with the companies concerned to alert them to the exposure of their data and ensure the information was secured, but making contact with those organizations and getting the data secured proved problematic, so Ursem contacted databreaches.net for assistance.

Together, Dissent Doe of DataBreaches.net and Ursem worked together to contact the organizations concerned and get the data secured. In some cases, they succeeded – with considerable effort – but even after several months of attempts at contacting the companies concerned, explaining the severity of the situation, and offering help to address the problems that led to the exposure of data, some of that data is still accessible.

9 Leaks Identified but There are Likely to be Others

The report details 9 leaks that affected U.S. entities – namely Xybion, MedPro Billing, Texas Physician House Calls, VirMedica, MaineCare, Waystar, Shields Health Care Group, AccQData – and one unnamed entity: Unnamed because the data is still accessible.

The most common causes of GitHub data leaks were developers who had embedded hard-coded credentials into code that had been uploaded into public GitHub repositories, the use of public repositories instead of private repositories, and developers who had abandoned repositories when they were no longer required, rather than securely deleting them.

For example, Ursem found that a developer at Xybion – a software, services and consulting company with a presence in workplace health issues – had left code in a public GitHub repository in February 2020. The code included hard-coded credentials for a system user that, in connection with other code, allowed Ursem to access billing back-office systems that contained the PHI of 7,000 patients, together with more than 11,000 insurance claims dating back to October 31, 2018.

It was a similar story with MaineCare – a state- and federally-funded program that provides healthcare coverage to Maine residents. In that case, hard-coded credentials gave Ursem administrative access to the entire website, access to the internal server infrastructure of MaineCare / Molina Health, MaineCare SQL data sources, and the PHI of 75,000 individuals.

The Typhoid Mary of Data Leaks

The report highlights one developer, who has worked with a large number of healthcare organizations, whose GitHub practices have led to the exposure of many credentials and the PHI of an estimated 200,000 clients. That individual has been called the “Typhoid Mary of Data Leaks”.

The developer made many mistakes that allowed client data to be exposed, including leaking the credentials of 5 employers on GitHub and leaving repositories fully accessible after work had been completed. In one case, the actions of that developer had allowed access to the central telephone system of a large entity in debt collection, and in another credentials allowed access to highly sensitive records for people with a history of substance abuse.

While it was not possible to contact that individual directly, it appears that the work of DataBreaches.net and Ursem has gotten the message through to the developer. The repositories have now been removed or made private, but not before the data was cloned by at least one third party.

This was just one example of several outsourced or contracted developers who were being used by HIPAA-covered entities and business associates, whose practices exposed data unbeknownst to the CEs and BAs.

“No matter how big or small you are, there’s a real chance that one of your employees has thrown the front door key under the doormat and has forgotten that the doormat is transparent,” explained Dissent Doe of DataBreaches.net. Regardless of whether your organization uses GitHub, HIPAA Journal believes the report to be essential reading.

The collaborative report from Jelle Ursem and DataBreaches.net explains how the leaks occurred, why they have gone undetected for so long, and details several recommendations on how data breaches on GitHub can be prevented – and detected and addressed quickly in the event that mistakes are made. You can download the full PDF report on this link.

Many thanks to Dissent Doe for notifying HIPAA Journal, to Jelle Ursem for discovering the data leaks, and for the hard work of both parties investigating the leaks, contacting the entities concerned, and highlighting the problem to help HIPAA-covered entities and their business associates take steps to prevent GitHub data breaches moving forward.

The post Healthcare Data Leaks on GitHub: Credentials, Corporate Data and the PHI of 150,000+ Patients Exposed appeared first on HIPAA Journal.

NIST Publishes Final Guidance on Establishing Zero Trust Architecture to Improve Cybersecurity Defenses

Posted by HIPAA Journal

NIST has published the final version of its zero trust architecture guidance document (SP 800-207) to help private sector organizations apply this cybersecurity concept to improve their security posture.

Zero trust is a concept that involves changing defenses from static, network-based perimeters to focus on users, assets, and resources. With zero trust, assets and user accounts are not implicitly trusted based on their physical or network location or asset ownership. Under the zero trust approach, authentication and authorization are discreet functions that occur with subjects and devices before a session is established with an enterprise resource.

The use of credentials for gaining access to resources has been an effective security measure to prevent unauthorized access; however, credential theft – through phishing campaigns for instance – is now commonplace, so cybersecurity defenses need to evolve to better protect assets, services, workflows, and network accounts from these attacks.

All too often, credentials are stolen and are used by threat actors to gain access to enterprise networks undetected. Threat actors often have access to networks for days, weeks, or even months before an attack is detected, during which time they are free to move laterally and compromise an entire network. The increase in remote working, bring your own device initiatives and the use of cloud-based assets that are not located within the traditional network boundary has made the traditional perimeter-based approach to network security less effective.

A zero trust architecture helps to solve these issues and improve cybersecurity defenses. According to NIST, “zero trust focuses on protecting resources (assets, services, workflows, network accounts, etc.), not network segments, as the network location is no longer seen as the prime component to the security posture of the resource.”

The guidance document provides an abstract definition of zero trust architecture (ZTA), covers the zero trust basics and logical components of zero trust architecture, and includes general deployment models and use cases where the zero trust approach can improve an organization’s information technology security posture.

In the guidance document NIST explains how the zero trust model can be combined with the NIST Risk Management Framework, NIST Privacy Framework, and other existing federal guidance and outlines how organizations can migrate to zero trust architecture.

Initially, organizations should focus on restricting access to resources to individuals who require access to perform their work duties, and to only grant minimal privileges such as read, write, delete. In many organizations with perimeter-based defenses, individuals tend to be given access to a much broader range of resources once they have been authenticated and logged in to an internal network. The problem with this approach is unauthorized lateral movement is too easy, either by internal actors or external actors using stolen credentails.

The zero trust security model assumes an attacker is present within an environment, so there is no implicit trust. Enterprise networks are treated the same as non-enterprise networks. Under the zero trust approach, organizations continually analyze and evaluate risks to assets and business functions and then enact protections to mitigate those risks.

Migrating to zero trust is not about the wholesale replacement of infrastructure or processes, rather it is a journey that involves incrementally introducing zero trust principles, processes, technology solutions, and workflows, starting with protecting the highest value assets. Most organizations will remain in a hybrid zero trust and perimeter-based environment for some time while they implement their IT modernization plan and fully transition to zero trust architecture.

The guidance document is the result of collaboration with several federal agencies and was overseen by the Federal CIO Council. The document was developed for enterprise security architects, but is also a useful resource for cybersecurity managers, network administrators, and managers to gain a better understanding of zero trust.

The publication can be downloaded from NIST on this link.

The post NIST Publishes Final Guidance on Establishing Zero Trust Architecture to Improve Cybersecurity Defenses appeared first on HIPAA Journal.

Patches Released to Fix Critical Vulnerabilities in Citrix Endpoint Management / XenMobile Server

Posted by HIPAA Journal

Two critical flaws have been found in Citrix Endpoint Management (CEM) / XenMobile Server. The flaws could be exploited by an unauthenticated attacker to access domain account credentials, take full control of a vulnerable XenMobile Server, and access VPN, email, and web applications and obtain sensitive corporate and patient data.

CEM/ XenMobile Server is used by many businesses to manage employees’ mobile devices, apply updates, manage security settings, and the toolkit is used to support many in-house applications. The nature of the flaws make it likely that hackers will move to develop exploits quickly, so immediate patching is essential.

The two critical flaws are tracked as CVE-2020-8208 and CVE-2020-8209. Information has only been released on one of the critical flaws – CVE-2020-8209 – which is a path traversal vulnerability due to insufficient input validation. If exploited, an unauthenticated attacker could read arbitrary files on the server running an application. Those files include configuration files and encryption keys could be obtained, which would allow sensitive data to be decrypted. The flaws could be exploited by convincing a user to visit a specially crafted webpage.

Andrey Medov of Positive Technologies was credited with discovering the flaw. “Exploitation of this vulnerability allows hackers to obtain information that can be useful for breaching the perimeter, as the configuration file often stores domain account credentials for LDAP access,” said Medev. With access to the domain account, a remote attacker can use the obtained data for authentication on other external company resources, including corporate mail, VPN, and web applications. Worse still, an attacker who has managed to read the configuration file can access sensitive data, such as database password (local PostgreSQL by default and a remote SQL Server database in some cases).”

The three other vulnerabilities, tracked as CVE-2020-8210, CVE-2020-8211 and CVE-2020-8212, are rated medium and low severity. Information on these flaws has not yet been released by Citrix.

The critical vulnerabilities affect:

  • XenMobile Server 10.12 prior to RP2
    • XenMobile Server 10.11 prior to RP4
    • XenMobile Server 10.10 prior to RP6
    • XenMobile Server prior to 10.9 RP5

The medium and low severity vulnerabilities affect:

  • XenMobile Server 10.12 prior to RP3
    • XenMobile Server 10.11 prior to RP6
    • XenMobile Server 10.10 prior to RP6
    • XenMobile Server prior to 10.9 RP5

Citrix believes it will not take long for hackers to develop exploits and start exploiting the flaws, so immediate patching is strongly recommended.

Citrix has released patches for XenServer versions 10.9, 10.10, 10.11, and 10.12. Customers using version 10.9x of XenServer must upgrade to a supported version of the software before the patch can be applied. An upgrade to 10.12 RP3 is recommended by Citrix. The cloud versions of XenMobile have been automatically updated, so no action is required.

The post Patches Released to Fix Critical Vulnerabilities in Citrix Endpoint Management / XenMobile Server appeared first on HIPAA Journal.

More than 1,000 Companies Targeted in New Business Email Compromise Scam

Posted by HIPAA Journal

More than 1,000 companies worldwide have been targeted in a business email compromise (BEC) campaign that has been running since March 2020.

The scam was uncovered by researchers at Trend Micro who report that more than 800 sets of Office 365 credentials have been compromised so far. Trend Micro has attributed the campaign to a cybercriminal group called Water Nue. While the group is not particularly technically sophisticated, the attacks have proven to be successful and the gang is extremely proficient.

Trend Micro identified the campaign when it appeared that a large number of email domains were being used to phish for credentials and most of the victims were individuals in high corporate positions.

The attackers target the Office 365 accounts of executives, particularly those working in finance. Cloud-based email distribution services are used to send emails containing malicious hyperlinks that direct the recipient to a fake Office 365 login page.

The emails claim a voicemail message has been left and a hyperlink is included that must be clicked to listen to the message. Clicking the link directs the recipient to a fake Office 365 domain that requires credentials to be entered to listen to the message. The credentials are harvested using a PHP script and are used to access executives’ email accounts. Fake invoices and documents are then created and sent to lower level employees.

Since the emails are sent from a known executive’s email account, the invoices are often paid without being questioned. The payments are sent to bank accounts under the control of the scammers. When the phishing attacks are discovered and domains are blacklisted, the group changes their infrastructure and uses new domains to continue their campaign.

Trend Micro said the phishing tools used by the group are basic, no malware is distributed, and cloud services such as SendGrid are used to obfuscate their operation. “The use of cloud services allowed them to obfuscate their operations by hosting infrastructures in the services themselves, making their activities tougher to spot for forensics. This tactic has become more commonplace among cybercriminals,” explained Trend Micro.

The campaign is ongoing, and the recent attacks indicate executives in companies in the United States and Canada are being targeted.

Since the emails do not include malicious attachments, they are often not identified as malicious by traditional security solutions and are delivered to inboxes. It is therefore important to ensure that all employees are educated about the threat and told to be on high alert and to scrutinize all emails they receive. Training should be provided to everyone from the CEO down on how to identify the scams and the actions that should be taken when a suspicious email is received. A system should also be implemented that includes multiple signoffs and verification protocols for invoices. Trend Micro also recommends turning on mail inspection for messages from sendgrid[.]net

The post More than 1,000 Companies Targeted in New Business Email Compromise Scam appeared first on HIPAA Journal.

FBI Urges Enterprises to Upgrade Windows 7 Devices to a Supported Operating System

Posted by HIPAA Journal

The FBI Cyber Division has issued a Private Industry Notification advising enterprises still using Windows 7 within their infrastructure to upgrade to a supported operating system due to the risk of security vulnerabilities in the Windows 7 operating system being exploited.

The FBI has observed an increase in cyberattacks on unsupported operating systems once they reach end-of-life status. Any organization that is still using Windows 7 on devices faces an increased risk of cybercriminals exploiting vulnerabilities in the operating system to remotely gain network access. “As time passes, Windows 7 becomes more vulnerable to exploitation due to lack of security updates and new vulnerabilities discovered,” warned the FBI.

The Windows 7 operating system reached end-of-life on January 14, 2020 and Microsoft stopped releasing free patches to correct known vulnerabilities. Microsoft is only providing security updates for Windows 7 Professional, Windows 7 Enterprise, and Windows 7 Ultimate if users sign up for the Extended Security Update (ESU) program. The ESU program will only run until January 2023, and the cost of continued support increases the longer a customer participates in the program. While security updates are being released for customers that have signed up for the ESU program, the FBI and Microsoft strongly advise users of Windows 7 to upgrade to Windows 10 or a fully supported operating system.

Updating an operating system is not without its challenges. New devices may need to be purchased and new software comes at a cost, but the cost will be negligible compared to the cost of the loss of intellectual properly and threats to an organization from the continued use of an operating system that is no longer supported.

Many organizations around the world are still using Windows 7 on at least some of their Windows devices. Data from Statcounter indicates around 20% of all Windows devices are still running Windows 7, even though free security updates are no longer being issued. An open source report published in May 2019 found that 71% of Windows devices used in healthcare were using Windows 7 or other operating systems that became unsupported in January 2020.

The FBI warned that increases in successful cyberattacks have been observed in healthcare when operating systems have reached end of life. When support for Windows XP ended on April 28, 2014, the industry saw a large increase in the number of exposed and compromised healthcare records the following year.

The FBI explained that cybercriminals are continuing to search for entry points into legacy Windows operating systems in order to leverage Remote Desktop Protocol (RDP) exploits. In May 2019, following the discovery of the BlueKeep vulnerability, Microsoft released patches for all supported operating systems and also a patch for Windows XP and other unsupported operating systems in order to prevent a WannaCry-style attack.  Since the vulnerability was discovered, working exploits have been developed to exploit the flaw and are still being used to attack unpatched Windows devices.

Vulnerabilities will be found and exploited on unpatched systems. When Microsoft released the MS17-010 patch to address several SMBv1 vulnerabilities in March 2017, many organizations were slow to apply the patch, even though there was a high risk exploitation. The WannaCry ransomware attacks exploiting the flaws started in May 2017. 98% of systems infected with WannaCry were running Windows 7.

“With fewer customers able to maintain a patched Windows 7 system after its end of life, cybercriminals will continue to view Windows 7 as a soft target” warned the FBI.

When organizations use an actively supported operating system, patches are automatically made available to fix newly discovered security vulnerabilities. Upgrading to a supported operating system is one of the most important steps to take to improve security.

“Defending against cyber criminals requires a multilayered approach, including validation of current software employed on the computer network and validation of access controls and network configurations,” explained the FBI in the alert.

In addition to upgrading the operating system and applying patches promptly, organizations should ensure antivirus software is installed, spam filters are used, and firewalls should be implemented, properly configured, and kept up to date.

Network configurations should be audited and any computer systems that cannot be updated should be isolated. The FBI also recommends auditing the network for systems using RDP and closing unused RDP ports. 2-factor authentication should be implemented as widely as possible and all RDP login attempts should be logged.

If there are reasons why Windows 7 devices cannot be updated and devices cannot be completely isolated, they should not be accessible over the internet and organizations should enroll in Microsoft’s ESU program.

The post FBI Urges Enterprises to Upgrade Windows 7 Devices to a Supported Operating System appeared first on HIPAA Journal.