STE WILLIAMS

A former General Electric (GE) engineer and Chinese businessman have been charged with economic espionage and conspiracy to steal GE’s trade secrets related to turbine technologies, with the intention of using the information to benefit the People’s Republic of China.

A 14-count indictment, unsealed today by the US Department of Justice(DoJ), alleges Xiaoqing Zheng, of New York, exploited his access to GE files during his time there as an engineer specializing in sealing technology. Officials allege Zheng stole multiple electronic files, including proprietary files containing design models, engineering drawings, configuration files, and material specifications related to various components and testing systems for GE’s gas and steam tribunes.

Zheng allegedly emailed and transferred this stolen data to his partner, Zhaoxi Zhang of China. Together they used the trade secrets to pursue their own interests in two Chinese corporations, Liaoning Tianyi Aviation Technology Co. (LTAT) and Nanjing Tianyi Avi Tech Co. (NTAT). Both organizations research, develop, and manufacture components for turbines, the DoJ reports.

Further, the DoJ says Zheng and Zhang conspired to commit economic espionage as the trade secret theft was done “knowing and intending” the data would benefit the People’s Republic of China in addition to other foreign entities. The defendants received financial support from the Chinese government via LTAT and NTAT; they also worked with government officials to participate in research agreements with state-owned institutions to build turbine technology.

Read more details here.

Join Dark Reading LIVE for two cybersecurity summits at Interop 2019. Learn from the industry’s most knowledgeable IT security experts. Check out the Interop agenda here.

Dark Reading’s Quick Hits delivers a brief synopsis and summary of the significance of breaking news events. For more information from the original source of the news item, please follow the link provided in this article. View Full Bio

Article source: https://www.darkreading.com/risk/two-charged-with-economic-espionage-ge-trade-secret-theft/d/d-id/1334519?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

Three years after the 2010 discovery of the Stuxnet attack that sabotaged a uranium enrichment process at the Natanz nuclear facility in Iran, researchers at Symantec found what they surmised was a precursor to the known payload that caused the plant’s centrifuges to spin out of control and fail. This early version of Stuxnet, which they called Stuxnet .5, targeted the Siemens PLC control systems that operate the valves that feed uranium hexafluoride gas into uranium enrichment centrifuges. Stuxnet .5 could close the valves and halt the release of depleted and enriched uranium gases, damaging the equipment and the manufacturing process.

The discovery led Symantec’s researchers to revise their time frame of the Stuxnet attack to 2005, two years earlier than the known 2007 to 2009 attacks on the Natanz centrifuges, which were believed to be launched by the US and Israel to derail the possible development of nuclear weapons in Iran.

Flash forward to now, six years after the 2013 Stuxnet .5 finding, and there’s yet another twist to the Stuxnet story. Researchers from Google’s Chronicle Security company earlier this month revealed that they have found evidence that a fourth cyber espionage group possibly assisted in Stuxnet’s attack campaign on the Natanz nuclear facility.

Chronicle’s Juan Andres Guerrero Saade and Silas Cutler uncovered a link between an older Stuxnet command-and-control component and an older cyber espionage platform called Flowershop – active as far back as 2002 and first discovered by Kaspersky Lab in 2015.

“What we realized was that this was essentially the early command-and-control module for Stuxnet – the older version of Stuxnet,” Stuxnet. 5, Guerrero Saade says.

Dubbed Stuxshop by Chronicle, the module communicates with known Stuxnet C2 servers and can eliminate dial-up prompts for machines that aren’t connected to the network. Stuxshop provides yet another clue to Stuxnet’s creation by multiple groups, they say: It already had been tied to Flame, Duqu, and the Equation Group nation-state cyber espionage families. Like the intel-gathering Flowershop code, Stuxshop’s features include checking an infected machine’s Windows version, Internet proxy settings, and registry key information.

“Stuxnet was the result of a collaborated framework with a bunch of different groups. It was a hodgepodge of plug-ins,” Guerrero Saade says.

The researchers say it appears some Flowershop code was used in the Stuxnet module, which could indicate that two attack development teams were working together or sharing code.

“Flowershop was its own intel-gathering platform, a whole different threat actor active for a decade. No one had been able to connect it to Stuxnet until we identified Stuxshop,” Guerrero Saade says. Stuxshop shares code from Flowershop, but it was specifically developed for the Stuxnet attack, he says.

The Chronicle researchers first disclosed their research at the Kaspersky Security Analyst Summit this month in Singapore.

Symantec’s Liam O’Murchu, one of the first researchers to study Stuxnet, says he hasn’t yet fully analyzed the Stuxshop files, but from his first read, it appears to fit the timeline of his company’s discovery of Stuxnet .5.

While O’Murchu and other Stuxnet experts say Chronicle’s new findings don’t dramatically alter the Stuxnet story, they do provide more confirmation of the timeline of the attack campaign. “To separately confirm the timeline is very good,” O’Murchu says.

It provides more evidence of Symantec’s longtime working theory that the Stuxnet operation dates back as far back as 2002.

“Stuxshop’s timeline fits in with what we had assumed the development timeline would be. We were looking specifically at the destructive part of Stuxnet, so that’s what we had,” says O’Murchu, who is director of development for the security technology and response team at Symantec. “We had assumed … there was a previous version actually gathering information.”

Costin Raiu, one of the lead researchers from Kaspersky Lab who hunted down Stuxnet, notes that Chronicle’s findings follow the threads of previous research, including his firm’s connecting Flowershop to Stuxnet in private reports to its clients in 2014. With the explosion in more advanced research tools, like the Yara malware investigation tool, and Chronicle’s access to its VirusTotal platform, researchers are now able to better fill in the gaps of information on advanced attacks like Stuxnet, he says.

“Chronicle truly has a unique advantage here because they have excellent sources of data: VirusTotal,” Raiu says.

Stuxshop and Stuxnet .5 were eventually replaced with Stuxnet 1.10 and its command-and-control infrastructure. Stuxnet 1.10 attacked Siemens PLC equipment that ran the Natanz plant’s centrifuges.

Rekindled Flame
Meantime, Guerrero Saade and Cutler recently found a surprise in their VirusTotal repository: a reincarnated version of the Flame cyber espionage platform, which was last seen in 2012 when it self-destructed. They christened the new variant Flame 2.0, but for now they’re unable to see inside it. “The payload is encrypted so we can’t really see what it’s doing,” Guerrero Saade says.

Flame 2.0 was apparently compiled sometime after 2014 and landed in VirusTotal in 2016. “I’ll bet AV companies are aware of it and we’ll find more samples of it,” he says.

The researchers are hoping to get help decrypting the sample from other security firms.

Kurt Baumgartner, a security researcher with Kaspersky Lab, says decrypting the newly found Flame 2.0 won’t be easy, pointing to the still-uncracked Gauss malware payload that has dogged researchers for seven years. “[Flame 2.0 is] probably not going to be cracked anytime soon,” he says.

Flame’s reappearance fits a profile of advanced threat groups that don’t really ever die. “Sometimes we lose visibility, but we never know if they are really gone. They may have just retooled, or disappeared altogether,” Symantec’s O’Murchu says.

Catching Up?
The Stuxshop discovery – nine years after Stuxnet was first found by researchers – underscores how the cyberweapon was ahead of its time and ahead of threat hunting capabilities and tools available to researchers in the private sector in the early 2000s, experts say. The Stuxnet campaign and its predecessor components had been well underway by the nation-state hackers long before security researchers uncovered it in 2010.

“We really weren’t cyberwar-trained until Stuxnet,” Symantec’s O’Murchu says of the security industry. “What we hope is that we’ve advanced to make it more difficult for them to do things and not be noticed. … I would hope we’ll be able to find them faster and see traces, but you never really know. We could be missing a bunch of stuff now” and then could find it years later, he says.

Related Content:

• PLC Worms Pose Stealthy Threat To Industrial Systems 
• Stuxnet Part Of Widespread Cyber-Intrusion Of Iranian Infrastructure, New Film Claims
• Duqu 2.0 Attack On Kaspersky Lab Opens Chilling New Chapter In Cyber Espionage
• Stuxnet Exploits Still Alive Well

Join Dark Reading LIVE for two cybersecurity summits at Interop 2019. Learn from the industry’s most knowledgeable IT security experts. Check out the Interop agenda here.

Kelly Jackson Higgins is Executive Editor at DarkReading.com. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise … View Full Bio

Article source: https://www.darkreading.com/threat-intelligence/stuxnet-family-tree-grows/d/d-id/1334511?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

Three years after the 2010 discovery of the Stuxnet attack that sabotaged a uranium enrichment process at the Natanz nuclear facility in Iran, researchers at Symantec found what they surmised was a precursor to the known payload that caused the plant’s centrifuges to spin out of control and fail. This early version of Stuxnet, which they called Stuxnet .5, targeted the Siemens PLC control systems that operate the valves that feed uranium hexafluoride gas into uranium enrichment centrifuges. Stuxnet .5 could close the valves and halt the release of depleted and enriched uranium gases, damaging the equipment and the manufacturing process.

The discovery led Symantec’s researchers to revise their time frame of the Stuxnet attack to 2005, two years earlier than the known 2007 to 2009 attacks on the Natanz centrifuges, which were believed to be launched by the US and Israel to derail the possible development of nuclear weapons in Iran.

Flash forward to now, six years after the 2013 Stuxnet .5 finding, and there’s yet another twist to the Stuxnet story. Researchers from Google’s Chronicle Security company earlier this month revealed that they have found evidence that a fourth cyber espionage group possibly assisted in Stuxnet’s attack campaign on the Natanz nuclear facility.

Chronicle’s Juan Andres Guerrero Saade and Silas Cutler uncovered a link between an older Stuxnet command-and-control component and an older cyber espionage platform called Flowershop – active as far back as 2002 and first discovered by Kaspersky Lab in 2015.

“What we realized was that this was essentially the early command-and-control module for Stuxnet – the older version of Stuxnet,” Stuxnet. 5, Guerrero Saade says.

Dubbed Stuxshop by Chronicle, the module communicates with known Stuxnet C2 servers and can eliminate dial-up prompts for machines that aren’t connected to the network. Stuxshop provides yet another clue to Stuxnet’s creation by multiple groups: It already had been tied to Flame, Duqu, and the Equation Group nation-state cyber espionage families. Like the intel-gathering Flowershop code, Stuxshop’s features include checking an infected machine’s Windows version, Internet proxy settings, and registry key information.

“Stuxnet was the result of a collaborated framework with a bunch of different groups. It was a hodgepodge of plug-ins,” Guerrero Saade says.

The researchers say it appears some Flowershop code was used in the Stuxnet module, which could indicate that two attack development teams were working together or sharing code.

“Flowershop was its own intel-gathering platform, a whole different threat actor active for a decade. No one had been able to connect it to Stuxnet until we identified Stuxshop,” Guerrero Saade says. Stuxshop shares code from Flowershop, but it was specifically developed for the Stuxnet attack, he says.

The Chronicle researchers first disclosed their research at the Kaspersky Security Analyst Summit this month in Singapore.

Symantec’s Liam O’Murchu, one of the first researchers to study Stuxnet, says he hasn’t yet fully analyzed the Stuxshop files, but from his first read, it appears to fit the timeline of his company’s discovery of Stuxnet .5.

While O’Murchu and other Stuxnet experts say Chronicle’s new findings don’t dramatically alter the Stuxnet story, they do provide more confirmation of the timeline of the attack campaign. “To separately confirm the timeline is very good,” O’Murchu says.

It provides more evidence of Symantec’s longtime working theory that the Stuxnet operation dates back as far back as 2002.

“Stuxshop’s timeline fits in with what we had assumed the development timeline would be. We were looking specifically at the destructive part of Stuxnet, so that’s what we had,” says O’Murchu, who is director of development for the security technology and response team at Symantec. “We had assumed … there was a previous version actually gathering information.”

Costin Raiu, one of the lead researchers from Kaspersky Lab who hunted down Stuxnet, notes that Chronicle’s findings follow the threads of previous research, including his firm’s connecting Flowershop to Stuxnet in private reports to its clients in 2014. With the explosion in more advanced research tools, like the Yara malware investigation tool, and Chronicle’s access to its VirusTotal platform, researchers are now able to better fill in the gaps of information on advanced attacks like Stuxnet, he says.

“Chronicle truly has a unique advantage here because they have excellent sources of data: VirusTotal,” Raiu says.

Stuxshop and Stuxnet .5 were eventually replaced with Stuxnet 1.10 and its command-and-control infrastructure. Stuxnet 1.10 attacked Siemens PLC equipment that ran the Natanz plant’s centrifuges.

Rekindled Flame
Meantime, Guerrero Saade and Cutler recently found a surprise in their VirusTotal repository: a reincarnated version of the Flame cyber espionage platform, which was last seen in 2012 when it self-destructed. They christened the new variant Flame 2.0, but for now they’re unable to see inside it. “The payload is encrypted so we can’t really see what it’s doing,” Guerrero Saade says.

Flame 2.0 was apparently compiled sometime after 2014 and landed in VirusTotal in 2016. “I’ll bet AV companies are aware of it and we’ll find more samples of it,” he says.

The researchers are hoping to get help decrypting the sample from other security firms.

Kurt Baumgartner, a security researcher with Kaspersky Lab, says decrypting the newly found Flame 2.0 won’t be easy, pointing to the still-uncracked Gauss malware payload that has dogged researchers for seven years. “[Flame 2.0 is] probably not going to be cracked anytime soon,” he says.

Flame’s reappearance fits a profile of advanced threat groups that don’t really ever die. “Sometimes we lose visibility, but we never know if they are really gone. They may have just retooled, or disappeared altogether,” Symantec’s O’Murchu says.

Catching Up?
The Stuxshop discovery – nine years after Stuxnet was first found by researchers – underscores how the cyberweapon was ahead of its time and ahead of threat hunting capabilities and tools available to researchers in the private sector in the early 2000s, experts say. The Stuxnet campaign and its predecessor components had been well underway by the nation-state hackers long before security researchers uncovered it in 2010.

“We really weren’t cyberwar-trained until Stuxnet,” Symantec’s O’Murchu says of the security industry. “What we hope is that we’ve advanced to make it more difficult for them to do things and not be noticed. … I would hope we’ll be able to find them faster and see traces, but you never really know. We could be missing a bunch of stuff now” and then could find it years later, he says.

Related Content:

• PLC Worms Pose Stealthy Threat To Industrial Systems 
• Stuxnet Part Of Widespread Cyber-Intrusion Of Iranian Infrastructure, New Film Claims
• Duqu 2.0 Attack On Kaspersky Lab Opens Chilling New Chapter In Cyber Espionage
• Stuxnet Exploits Still Alive Well

Join Dark Reading LIVE for two cybersecurity summits at Interop 2019. Learn from the industry’s most knowledgeable IT security experts. Check out the Interop agenda here.

Kelly Jackson Higgins is Executive Editor at DarkReading.com. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise … View Full Bio

Article source: https://www.darkreading.com/threat-intelligence/stuxnet-family-tree-grows/d/d-id/1334511?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

The collective efforts of hackers have fundamentally changed the cyber defense game. Today, adversarial automation is being used to create and launch new attacks at such a rate and volume that every strain of malware must now be considered a zero day and every attack considered an advanced persistent threat.

That’s not hyperbole. According to research by AV-Test, more than 121.6 million new malware samples were discovered in 2017. That is more than 333,000 new samples each day, more than 230 new samples each minute, nearly four new malware samples every second.

When malicious, morphing malware is unleashed at that scale, traditional defenses are quickly overwhelmed. Signature-based detection only works for known threats. Sandboxing-based detection techniques can’t keep up because there isn’t enough time and resources to analyze and identify attack signatures when your enterprise is being bombarded with malware variants that have never been seen before.

Stopping malware attacks the first time is an ideal that has remained tantalizingly out of reach, and so success measured over time became the standard—a standard that has been obviated by the insidiously effective nature of malware. If an attack succeeds once but is stopped on 99 subsequent attacks, that’s a 99% success rate. To achieve that, however someone has to be “Patient Zero.” Someone must take one for the team so that the intelligence gained from that first attack can be shared and used to prevent subsequent attacks. But when attacks are launched at a massive, global scale, and when there are more than 121 million new samples every year, there’s never just one Patient Zero. And it’s no fun if you happen to be among them.

Thanks to advancements in the development of automation, artificial intelligence and deep learning, there may be hope. (Editor’s note: Blue Hexagon is one of several early innovators developing security products based on deep learning.)

Deep learning is a type of machine learning that uses artificial neural networks to make decisions. Artificial neural networks are not new, but recent advancements in processing have increased their capabilities. At the same time the costs of the underlying tech have lowered, putting deep learning applications within the reach of many industries — including cybersecurity. In fact, deep learning’s capabilities are an ideal application for addressing many of the challenges that continue to stymie efforts to secure networks against hacking’s daily onslaught.

Fundamentally cybersecurity is about data and patterns, and there is a huge pool of threat data available through threat intelligence services and repositories that has been aggregated over the years and that can be used to inform deep learning-based defenses. By exposing neural nets to the vast threat data set, deep learning can learn to identify malicious traffic, even if the specific attack is brand new.

This is not theoretical. Deep learning has been applied at network entry points — both on-premises and in the cloud — to inspect traffic in early, live customer deployments, where it has successfully detected and blocked polymorphic malware, including Emotet variants, on first encounter. The underlying architecture ensures that threat analysis, verdict, and prevention occur in seconds, keeping malware out of the network in real time.

It’s early days yet, and while there has been no independent testing disclosed to date, the potential for deep learning to make a quantum leap is in evidence. In our lab and beta test environments, we have consistently achieved nearly 100% detection rates for all threats encountered, including both known samples and zero days, regardless of OS or application. We are also pursuing independent testing to verify these results.

This is important because hackers have developed techniques to evade and defeat traditional defenses such as sandboxes and signatures. These results suggest that the industry may have reached a point where stemming the tide of threat escalation is achievable and the traditional game of cybersecurity whack-a-mole — where threat actors create and distribute new malware, security vendors identify the new strain and distribute its signature, and threat actors would respond by creating more new malware strains — may be at an end.

When attackers realized they could use automation to generate and distribute malware variants faster than the industry could react, they embraced their new ability with enthusiasm. If deep learning gives our industry the means to return fire and blunt their attacks with overwhelming speed and intelligence, we should likewise embrace our newfound power.

Related Content:

• 6 Essential Skills Cybersecurity Pros Need to Develop in 2019
• Emotet Malware Gets More Aggressive
• When Your Sandbox Fails

 Join Dark Reading LIVE for two cybersecurity summits at Interop 2019. Learn from the industry’s most knowledgeable IT security experts. Check out the Interop agenda here.

Saumitra Das is the CTO and Co-Founder of Blue Hexagon. He has worked on machine learning and cybersecurity for 18 years. As an engineering leader at Qualcomm, he led teams of machine learning scientists and developers in the development of ML-based products shipped in … View Full Bio

Article source: https://www.darkreading.com/vulnerabilities---threats/when-every-attack-is-a-zero-day/a/d-id/1334468?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

Malware authors weaponized more Adobe software vulnerabilities in 2018 than any previous year while the actual number of newly disclosed security flaws in the company’s products dropped significantly since reaching an all-time-high in 2016.

Security vendor RiskSense recently analyzed over 20 years of Adobe vulnerability data gathered from Adobe’s own security bulletins and numerous third-party sources, including bug bounty programs and the national vulnerability database.

The analysis showed that of the 374 new Adobe vulnerabilities disclosed in 2018, exploits or malware became available for 177—or 47%—of them. Fifty of the vulnerabilities were weaponized even before a patch was available.

The numbers are significantly higher than previous years both in terms of the percentage of new vulnerabilities that were weaponized, and in terms of the number of Adobe flaws that were exploitable before patch availability. In 2017, for instance, just 21% of the vulnerabilities disclosed had associated exploits and malware. Similarly, the rate of exploits in the wild before patch availability was some three times higher last year than the previous high set in 2010, RiskSense said.

Ironically, the increased and accelerated weaponization of Adobe vulnerabilities happened during a year in which the overall number of new vulnerabilities disclosed was 31% lower than the record 538 vulnerabilities reported in 2016.

“2018 was definitely exceptional in terms of the weaponization of [Adobe] vulnerabilities,” says Anand Paturi, manager of product research for RiskSense. What’s not clear is whether the numbers are an anomaly or are indicative of a new trend, he says.

Paturi says that while malware authors were responsible for weaponizing some vulnerabilities, security researchers contributed to the situation as well by releasing proof-of-exploit code for Adobe flaws, sometimes before patch availability.  

“While this code is often very important for helping to understand the vulnerability and demonstrate its severity, this information can also sometimes accelerate the development of threats by attackers,” Paturi says.

Acrobat Reader, Flash Player Most Vunlerable

RiskSense’s study found that a total of 2,891 vulnerabilities were reported in Adobe products between 1996 and the end of 2018—a vast majority of them in Acrobat Reader and Flash Player. Reader accounted for 1,338 vulnerabilities, while Flash Player had 1,083.

Adobe’s cloud-hosted Acrobat DC was another big contributor to the overall vulnerability count, with 300 since the product’s 2015 launch. Nearly four-in-ten (38%) of the reported vulnerabilities in Adobe’s products over the past 20 years were buffer overflows.

Exploits and malware are currently available for 721 of the vulnerabilities, of which 152 are either remotely exploitable, enable privilege escalation, or are associated with Web apps.

Security experts in recent years have considered Flash Player in particular as a major security threat because of the number of vulnerabilities—including numerous zero-days—that have been discovered in the product over the years. Attackers have frequently exploited Flash vulnerabilities to attack users across multiple platforms, and exploits for these flaws have been a staple in exploit kits such as Neutrino and Angler for years.

However, Adobe’s decision to kill off Flash Player by 2020 has resulted in an overall decline in attacker interest in the technology – and a renewed focus on Acrobat Reader instead, Paturi says. Last year, there were just 24 reported Flash Player vulnerabilities.

This was a result of both Flash Player becoming less popular and of browser vendors adding security improvements to address Flash-related threats. “This has shifted attention to Adobe Acrobat Reader,” Paturi note. “As the browser-based exploits of Flash have dried up, attackers are having to work a bit harder and are shifting attention back to attacking Reader,” he says.

“Specifically, we are seeing a spike in remote code execution (RCE) exploits in Acrobat Reader and we expect to see that continue to rise.”

Related Content:

• Adobe’s Move to Kill Flash Is Good for Security
• Adobe Flash Zero-Day Spreads via Office Docs
• Adobe Flash Flaws Dominate Exploit Kits In 2016
• 8 Threats That Could Sink Your Company

Join Dark Reading LIVE for two cybersecurity summits at Interop 2019. Learn from the industry’s most knowledgeable IT security experts. Check out the Interop agenda here.

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year … View Full Bio

Article source: https://www.darkreading.com/vulnerabilities---threats/exploits-for-adobe-vulnerabilities-spiked-in-2018/d/d-id/1334506?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

For travelers, finding available Wi-Fi hotspots has become a task on the same level as finding public restrooms or drinkable coffee — one of the necessities of modern life. Travelers who turned to a free Android app called WiFi Finder might have found a convenient hotspot, but in doing so they potentially helped hackers find thousands of private wireless networks.

Security researcher Sanyam Jain found the database used by WiFi Finder was open to the Internet, unprotected by either authentication or encryption. Within that database were Wi-Fi network names, their precise geolocations, basic service set identifiers (BSSIDs), and network passwords for thousands of Wi-Fi networks, both public and private.

The same feature — allowing users to pull up login information for Wi-Fi hotspots — that provided login convenience for public networks created a huge security issue for home and private business networks.

“The HotSpot finder app presumes their user has the authority to disclose potentially sensitive information and thus can consent to the app receiving and potentially storing that data,” says Tim Mackey, senior technical evangelist at Synopsis. “This then creates a situation where the threat model defined by the WiFi network owner might be insufficient.”

The database has been taken offline by the hosting provider, but Mackey recommends that Wi-Fi network administrators change passwords. He also advises using this as a reminder that regular network monitoring and a process of password changes are reasonable security steps for any network.

Read more here.

Join Dark Reading LIVE for two cybersecurity summits at Interop 2019. Learn from the industry’s most knowledgeable IT security experts. Check out the Interop agenda here.

Dark Reading’s Quick Hits delivers a brief synopsis and summary of the significance of breaking news events. For more information from the original source of the news item, please follow the link provided in this article. View Full Bio

Article source: https://www.darkreading.com/vulnerabilities---threats/app-exposes-wi-fi-credentials-for-thousands-of-private-networks/d/d-id/1334508?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

A ransomware attack targeting the city of Stuart, Fla., is believed to have started with a phishing email, officials say. The incident struck on April 13 and affected city servers and computers.

An investigation revealed it was the Ryuk strain of ransomware that targeted city machines and forced them offline. City manager David Dyess did not disclose the Bitcoin ransom demanded; he did report investigators are analyzing an infected machine to determine how the virus got in. Ryuk is the same ransomware seen in attacks against Jackson County, Ga., and Albany, N.Y.

So far, he says, it seems a brute-force attack is not to blame. Given the infected machine is a desktop computer with no external connectivity, officials think a phishing email could have been the attack vector. So far, Stuart has restored servers for functions including payroll, utilities, and budgeting; however, city employees still don’t have access to their email accounts.

As of the latest update, Stuart’s police and fire departments are still offline. Dyess expects service should be restored within the next week and a half, TCPalm reports.

Read more details here.

Join Dark Reading LIVE for two cybersecurity summits at Interop 2019. Learn from the industry’s most knowledgeable IT security experts. Check out the Interop agenda here.

Dark Reading’s Quick Hits delivers a brief synopsis and summary of the significance of breaking news events. For more information from the original source of the news item, please follow the link provided in this article. View Full Bio

Article source: https://www.darkreading.com/endpoint/city-of-stuart-still-recovering-from-ryuk-ransomware-attack-/d/d-id/1334510?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple