Healthcare Cybersecurity

Study Reveals Increase in Credential Theft via Spoofed Login Pages

Posted by HIPAA Journal

A new study conducted by IRONSCALES shows there has been a major increase in credential theft via spoofed websites. IRONSCALES researchers spent the first half of 2020 identifying and analyzing fake login pages that imitated major brands. More than 50,000 fake login pages were identified with over 200 brands spoofed.

The login pages are added to compromised websites and other attacker-controlled domains and closely resemble the genuine login pages used by those brands. In some cases, the fake login is embedded within the body of the email.

The emails used to direct unsuspecting recipients to the fake login pages use social engineering techniques to convince recipients to disclose their usernames and passwords, which are captured and used to login to the real accounts for a range of nefarious purposes such as fraudulent wire transfers, credit card fraud, identity theft, data extraction, and more.

IRONSCALES researchers found the brands with the most fake login pages closely mirrored the brands with the most active phishing websites. The brand with the most fake login pages – 11,000 – was PayPal, closely followed by Microsoft with 9,500, Facebook with 7,500, eBay with 3,000, and Amazon with 1,500 pages.

While PayPal was the most spoofed brand, fake Microsoft login pages pose the biggest threat to businesses. Stolen Office 365 credentials can be used to access corporate Office 365 email accounts which can contain a range of highly sensitive data and, in the case of healthcare organizations, a considerable amount of protected health information.

Other brands that were commonly impersonated include Adobe, Aetna, Alibaba, Apple, AT&T, Bank of America, Delta Air Lines, DocuSign, JP Morgan Chase, LinkedIn, Netflix, Squarespace, Visa, and Wells Fargo.

The most common recipients of emails in these campaigns with individuals working in the financial services, healthcare and technology industries, as well as government agencies.

Around 5% of the fake login pages were polymorphic, which for one brand included more than 300 permutations. Microsoft login pages had the highest degree of polymorphism with 314 permutations. The reason for the high number of permutations of login pages is not fully understood. IRONSCALES suggests this is because Microsoft and other brands are actively searching for fake login pages imitating their brand. Using many different permutations makes it harder for human and technical controls to identify and take down the pages.

The emails used in these campaigns often bypass security controls and are delivered to inboxes. “Messages containing fake logins can now regularly bypass technical controls, such as secure email gateways and SPAM filters, without much time, money or resources invested by the adversary,” explained IRONSCALES. “This occurs because both the message and the sender are able to pass various authentication protocols and gateway controls that look for malicious payloads or known signatures that are frequently absent from these types of messages.”

Even though the fake login pages differ slightly from the login pages they spoof, they are still effective and often successful if a user arrives at the page. IRONSALES attributes this to “inattentional blindness”, where individuals fail to perceive an unexpected change in plain sight.

The post Study Reveals Increase in Credential Theft via Spoofed Login Pages appeared first on HIPAA Journal.

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.