Daily Archives: January 8, 2019

SN 696: Here Comes 2019!

  • The NSA announces the forthcoming release of an internal powerful reverse-engineering tool for examining and understanding other people's code.
  • Emergency out-of-cycle patches from both Adobe and Microsoft.
  • PewDiePie hacker strikes again.
  • Prolific 0-day dropper SandboxEscaper ruffles some feathers.
  • A new effort by the US government to educate industry about the risks of Cyber attacks.
  • Welcome news on the ransomware front.
  • VERY welcome news of a new Windows 10 feature.
  • A note about a just-published side-channel attack on OS page caches.

We invite you to read our show notes.

Hosts: Steve Gibson and Leo Laporte

Download or subscribe to this show at https://twit.tv/shows/security-now.

You can submit a question to Security Now! at the GRC Feedback Page.

For 16kbps versions, transcripts, and notes (including fixes), visit Steve's site: grc.com, also the home of the best disk maintenance and recovery utility ever written Spinrite 6.

Sponsors:

What to Expect in Cybersecurity for 2019

Technological advancements, an evolving threat landscape, and sophisticated nation-state actors will impact how organizations mitigate risk in the coming year.


Category:

Information Security
Leadership Insights

Technological advancements, an evolving threat landscape, and sophisticated nation-state actors will impact how organizations mitigate risk in the coming year.

Risky Business #525 — Back on deck for 2019!

In this week’s show Adam Boileau and Patrick Gray discuss the security news of the last few weeks, including:

  • German politicians pwnt, suspect arrested
  • Possible ransomware attack affects US newspapers
  • Mass 2FA bypasses impacting Gmail users in Middle East
  • Emergency warning system in Australia popped
  • Ethereum Classic double-spend attack a sign of things to come
  • EU to fund open source bug bounties
  • Attackers steal details of 1,000 North Korean defectors
  • Doing the Bloomberg hack for real at 35C3
  • El Chapo should have used Signal
  • Much, much more…

This week’s show is brought to you by Cylance! BlackBerry announced that it’s acquiring Cylance for $1.4bn (I don’t know if that’s closed yet) which is great news for all the founders and early employees there – some of whom I know reasonably well. So congrats to team Cylance on that!

But we’re not talking about that this week. Instead, Cylance’s very own Scott Scheferman joins us to talk about the MITRE ATT&CK framework and how it’s informing their product dev. There’s some product talk in that interview but there’s also some real meat there so I let it run long. Scott says we’re close to the terrible situation where security companies are going to start using MITRE ATT&CK as a marketing tool, like “Full MITRE ATT&CK coverage!”

Links to everything that we discussed are below and you can follow Patrick or Adam on Twitter if that’s your thing.

Show notes

Arrested German hacker confesses to leaking politicians' information, report says
Before Germany’s Massive Hack, We Learned What Not to Do With Sensitive Stolen Information - Motherboard
What we still don’t know about the cyberattack on Tribune newspapers - The Washington Post
Ransomware suspected in cyberattack that crippled major US newspapers | ZDNet
How Hackers Bypass Gmail 2FA at Scale - Motherboard
Hackers target 'hundreds' of Middle East activists with fake login pages, 2FA bypass schemes
Hackers send fake emergency emails, texts, messages using warning system
Coinbase suspends Ethereum Classic (ETC) trading after double-spend attacks | ZDNet
I Gave a Bounty Hunter $300. Then He Located Our Phone - Motherboard
EU to fund bug bounty programs for 14 open source projects starting January 2019 | ZDNet
Hackers hijack thousands of Chromecasts to warn of latest security bug | TechCrunch
Hackers steal personal info of 1,000 North Korean defectors | ZDNet
Modchips - Trammell Hudson's Projects
Hacking Group Decrypts Cache of Insurance Files Related to 9/11 Attacks - Motherboard
Hackers Make a Fake Hand to Beat Vein Authentication - Motherboard
You Can Now Get $1 Million for Hacking WhatsApp and iMessage - Motherboard
Alan Feuer on Twitter: "In February 2010, an undercover FBI agent met with the target of a sensitive investigation: Christian Rodriguez, an IT specialist who had recently developed a remarkable product: an encrypted communication network for the Mexican drug lord El Chapo and his Colombian partners."
Encrypted Messaging App Signal Says It Won’t Comply With Australia’s New Backdoor Bill - Motherboard
Louis Theroux among those hit by Twitter hack exposing security flaw | Technology | The Guardian
NSA to release a free reverse engineering tool | ZDNet
Open-source tool aims to curb BGP hijacking amid Chinese espionage concerns
ARTEMIS — neutralizing BGP hijacking within a minute | APNIC Blog
New hardware-agnostic side-channel attack works against Windows and Linux | ZDNet
1901.01161.pdf
Презентация PowerPoint
CVE-2019-0547 | Windows DHCP Client Remote Code Execution Vulnerability

Verizon Teams Up with McAfee to Secure Today’s Connected Home

Few fields and industries change as rapidly as those in the technology sector. This fast-moving, adaptable and growing sector creates new applications, new devices, and new efficiencies designed to make our everyday lives easier — sometimes in ways we’ve never imagined. But more devices and applications, from a security standpoint, means cybercriminals could have more opportunities to take advantage of flaws to conduct attacks. Additionally, the rapid growth in both software and hardware means today’s consumers are tasked with securing a plethora of personal devices.

This is not a sustainable path to a secure today’s technology landscape, one that’s continually growing and changing with each new addition. If we are going to continue to build a robust future, one including the rich potential inherent in Internet of Things (IoT) devices, we need a dynamic security solution that scales to meet the needs of modern-day society.

And that need is growing. According to a study from Market Research Future, the IoT market is set to potentially reach $124 billion in value by 2023 — only five years from now. Plus, Gartner predicts that there will be over 20 billion smart devices by 2020. That number is likely to grow, too.

That’s why we’ve worked with Verizon to launch Home Network Protection (HNP), a comprehensive security platform powered by McAfee Secure Home Platform, which has been designed to help safeguard consumers’ home networks. It does so through a robust, secure router designed to shield both traditional and newer IoT devices from malicious websites. It’s a proactive approach designed to keep consumer devices as safe as possible.

Customers using Fios by Verizon, a 100 percent fiber-optic network, and the Fios Quantum Gateway router can use HNP to secure their internet-connected devices, including smart cameras, baby monitors, television sets, and thermostats.

This is a massive milestone for consumer security in today’s digital age. Through a single provider, millions of consumers can access seamless protection from the latest threats — making modern conveniences easier to secure.

The post Verizon Teams Up with McAfee to Secure Today’s Connected Home appeared first on McAfee Blogs.

Cash Out with Our CES 2019 #RT2Win Sweepstakes!

We’ve officially touched down in Las Vegas for CES 2019!

If you aren’t familiar with CES, it is the global stage for innovators to showcase the next generation of consumer technologies. With the growing consumer technology landscape, we understand the importance of creating new solutions for those who want to live their connected lives with confidence. That’s why we’ve made some exciting new additions to our security lineup and employed multiple partnerships with other innovators like Google and Verizon to help protect users’ online safety. Check out all the details, here.

To celebrate the latest innovations, we’re giving two [2] lucky people the chance to win a $500 Amazon gift card. Not heading to CES this year? No problem! Simply retweet one of our official contest tweets with the required hashtags between January 8th – 11th for your chance to win. Follow the instructions below to enter, and good luck!

#RT2Win Sweepstakes Official Rules

  • To enter, follow @McAfee_Home on Twitter and find the #RT2Win sweepstakes tweet.
  • The sweepstakes tweet will be released on Tuesday, January 8, 2019 at 8:00 a.m. PT. This tweet will include the hashtags: #McAfeeAtCES, #RT2Win, AND #Sweepstakes.
  • Retweet the sweepstakes tweet released on the above date from your own handle. The #McAfeeAtCES, #RT2Win AND #Sweepstakes hashtags must be included to be entered.
  • Make sure you’re following @McAfee_Home on Twitter! You must follow for your entry to count.
  • Sweepstakes will end on Friday, January 11, 2019 at 11:59 p.m. PST. All entries must be made before that date and time.
  • Winners will be notified on Monday, January 14, 2019 via Twitter direct message.
  • Limit one entry per person.
1. How To Win

Retweet one of our contest tweets on @McAfee_Home that include “#McAfeeAtCES, #RT2Win, AND #Sweepstakes” for a chance to win a $500 Amazon gift card (for full prize details please see “Prizes” section below). Two [2] total winners will be selected and announced on January 14, 2019. Winners will be notified by direct message on Twitter. For full Sweepstakes details, please see the Terms and Conditions, below.

#RT2Win Sweepstakes Terms and Conditions

2. How to Enter: 

No purchase necessary. A purchase will not increase your chances of winning. McAfee CES 2019 #RT2Win Sweepstakes will be conducted from January 8, 2019 through January 11, 2019. All entries for each day of the McAfee CES 2019 #RT2Win Sweepstakes must be received during the time allotted for the McAfee CES 2019 #RT2Win Sweepstakes. Pacific Daylight Time shall control the McAfee CES 2019 #RT2Win Sweepstakes, duration is as follows:

  • Begins: Tuesday, January 8, 2019­­ at 8:00 a.m. PST
  • Ends: Friday, January 11, 2019 at 11:59 p.m. PST
  • Two [2] winners will be announced: Monday, January 14, 2019

For the McAfee CES 2019 #RT2Win Sweepstakes, participants must complete the following steps during the time allotted for the McAfee CES 2019 #RT2Win Sweepstakes:

  1. Follow @McAfee_Home on Twitter.
  2. Find the sweepstakes tweet of the day posted on @McAfee_Home which will include the hashtags: #McAfeeAtCES, #RT2Win and #Sweepstakes.
  3. Retweet the sweepstakes tweet of the day and make sure it includes the #McAfeeAtCES, #RT2Win, and hashtags.
  4. Note: Tweets that do not contain the #McAfeeAtCES, #RT2Win, and #Sweepstakes hashtags will not be considered for entry.
  5. Limit one entry per person.

Two [2] winners will be chosen for the McAfee CES 2019 #RT2Win Sweepstakes tweet from the viable pool of entries that retweeted and included #McAfeeAtCES, #RT2Win and #Sweepstakes. McAfee and the McAfee social team will choose winners from all the viable entries. The winners will be announced and privately messaged on Monday, January 14, 2019 on the @McAfee_Home Twitter handle. No other method of entry will be accepted besides Twitter. Only one entry per user is allowed, per Sweepstakes.   

3. Eligibility:

McAfee CES 2019 #RT2Win Sweepstakes is open to all legal residents of the 50 United States who are 18 years of age or older on the dates of the McAfee CES 2019 #RT2Win Sweepstakes begins and live in a jurisdiction where this prize and McAfee CES 2019 #RT2Win Sweepstakes not prohibited. Employees of Sponsor and its subsidiaries, affiliates, prize suppliers, and advertising and promotional agencies, their immediate families (spouses, parents, children, and siblings and their spouses), and individuals living in the same household as such employees are ineligible.

4. Winner Selection:

Winners will be selected at random from all eligible retweets received during the McAfee CES 2019 #RT2Win Sweepstakes drawing entry period. Sponsor will select the names of two [2] potential winners of the prizes in a random drawing from among all eligible submissions at the address listed below. The odds of winning depend on the number of eligible entries received. By participating, entrants agree to be bound by the Official McAfee CES 2019 #RT2Win Sweepstakes Rules and the decisions of the coordinators, which shall be final and binding in all respects.

5. Winner Notification: 

Each winner will be notified via direct message (“DM”) on Twitter.com by January 14, 2019. Prize winners may be required to sign an Affidavit of Eligibility and Liability/Publicity Release (where permitted by law) to be returned within ten (10) days of written notification, or prize may be forfeited, and an alternate winner selected. If a prize notification is returned as unclaimed or undeliverable to a potential winner, if potential winner cannot be reached within twenty four (24) hours from the first DM notification attempt, or if potential winner fails to return requisite document within the specified time period, or if a potential winner is not in compliance with these Official Rules, then such person shall be disqualified and, at Sponsor’s sole discretion, an alternate winner may be selected for the prize at issue based on the winner selection process described above.

6. Prizes: 

The prize for the McAfee CES 2019 #RT2Win Sweepstakes is a $500 Amazon gift card for each of the two [2] entrants/winners. Entrants agree that Sponsor has the sole right to determine the winners of the McAfee CES 2019 #RT2Win Sweepstakes and all matters or disputes arising from the McAfee CES 2019 #RT2Win Sweepstakes and that its determination is final and binding. There are no prize substitutions, transfers or cash equivalents permitted except at the sole discretion of Sponsor. Sponsor will not replace any lost or stolen prizes. Sponsor is not responsible for delays in prize delivery beyond its control. All other expenses and items not specifically mentioned in these Official Rules are not included and are the prize winners’ sole responsibility.

Limit one (1) prize per person/household. Prizes are non-transferable, and no cash equivalent or substitution of prize is offered. The McAfee CES 2019 #RT2Win Sweepstakes has no affiliation with Amazon.

7. General Conditions: 

Entrants agree that by entering they agree to be bound by these rules. All federal, state, and local taxes, fees, and surcharges on prize packages are the sole responsibility of the prizewinner. Sponsor is not responsible for incorrect or inaccurate entry information, whether caused by any of the equipment or programming associated with or utilized in the McAfee CES 2019 #RT2Win Sweepstakes, or by any technical or human error, which may occur in the processing of the McAfee CES 2019 #RT2Win Sweepstakes. entries. By entering, participants release and hold harmless Sponsor and its respective parents, subsidiaries, affiliates, directors, officers, employees, attorneys, agents, and representatives from any and all liability for any injuries, loss, claim, action, demand, or damage of any kind arising from or in connection with the McAfee CES 2019 #RT2Win Sweepstakes, any prize won, any misuse or malfunction of any prize awarded, participation in any McAfee CES 2019 #RT2Win Sweepstakes -related activity, or participation in the McAfee CES 2019 #RT2Win Sweepstakes. Except for applicable manufacturer’s standard warranties, the prizes are awarded “AS IS” and WITHOUT WARRANTY OF ANY KIND, express or implied (including any implied warranty of merchantability or fitness for a particular purpose).

8. Limitations of Liability; Releases:

By entering the Sweepstakes, you release Sponsor and all Released Parties from any liability whatsoever, and waive any and all causes of action, related to any claims, costs, injuries, losses, or damages of any kind arising out of or in connection with the Sweepstakes or delivery, misdelivery, acceptance, possession, use of or inability to use any prize (including claims, costs, injuries, losses and damages related to rights of publicity or privacy, defamation or portrayal in a false light, whether intentional or unintentional), whether under a theory of contract, tort (including negligence), warranty or other theory.

To the fullest extent permitted by applicable law, in no event will the sponsor or the released parties be liable for any special, indirect, incidental, or consequential damages, including loss of use, loss of profits or loss of data, whether in an action in contract, tort (including, negligence) or otherwise, arising out of or in any way connected to your participation in the sweepstakes or use or inability to use any equipment provided for use in the sweepstakes or any prize, even if a released party has been advised of the possibility of such damages.

  • To the fullest extent permitted by applicable law, in no event will the aggregate liability of the released parties (jointly) arising out of or relating to your participation in the sweepstakes or use of or inability to use any equipment provided for use in the sweepstakes or any prize exceed $10. The limitations set forth in this section will not exclude or limit liability for personal injury or property damage caused by products rented from the sponsor, or for the released parties’ gross negligence, intentional misconduct, or for fraud.
  • Use of Winner’s Name, Likeness, etc.: Except where prohibited by law, entry into the Sweepstakes constitutes permission to use your name, hometown, aural and visual likeness and prize information for advertising, marketing, and promotional purposes without further permission or compensation (including in a public-facing winner list).  As a condition of being awarded any prize, except where prohibited by law, winner may be required to execute a consent to the use of their name, hometown, aural and visual likeness and prize information for advertising, marketing, and promotional purposes without further permission or compensation. By entering this Sweepstakes, you consent to being contacted by Sponsor for any purpose in connection with this Sweepstakes.
9. Prize Forfeiture:

If winner cannot be notified, does not respond to notification, does not meet eligibility requirements, or otherwise does not comply with the prize McAfee CES 2019 #RT2Win Sweepstakes rules, then the winner will forfeit the prize and an alternate winner will be selected from remaining eligible entry forms for each McAfee CES 2019 #RT2Win Sweepstakes.

10. Dispute Resolution:

Entrants agree that Sponsor has the sole right to determine the winners of the McAfee CES 2019 #RT2Win Sweepstakes and all matters or disputes arising from the McAfee CES 2019 #RT2Win Sweepstakes and that its determination is final and binding. There are no prize substitutions, transfers or cash equivalents permitted except at the sole discretion of Sponsor.

11. Governing Law & Disputes:

Each entrant agrees that any disputes, claims, and causes of action arising out of or connected with this sweepstakes or any prize awarded will be resolved individually, without resort to any form of class action and these rules will be construed in accordance with the laws, jurisdiction, and venue of the State of New York, U.S.A.

12. Privacy Policy: 

Personal information obtained in connection with this prize McAfee CES 2019 #RT2Win Sweepstakes will be handled in accordance policy set forth at http://www.mcafee.com/us/about/privacy.html.

  1. Winner List; Rules Request: For a copy of the winner list, send a stamped, self-addressed, business-size envelope for arrival after January 8, 2019 before January 11, 2019 to the address listed below, Attn: #RT2Win at CES Sweepstakes.  To obtain a copy of these Official Rules, visit this link or send a stamped, self-addressed business-size envelope to the address listed in below, Attn: Sarah Grayson. VT residents may omit return postage.
  2. Intellectual Property Notice: McAfee and the McAfee logo are registered trademarks of McAfee, LLC. The Sweepstakes and all accompanying materials are copyright © 2019 by McAfee, LLC.  All rights reserved.
  3. Sponsor: McAfee, LLC, Corporate Headquarters 2821 Mission College Blvd. Santa Clara, CA 95054 USA
  4. Administrator: LEWIS Pulse, 111 Sutter St., Suiter 850, San Francisco, CA 94104

The post Cash Out with Our CES 2019 #RT2Win Sweepstakes! appeared first on McAfee Blogs.

Learn just what a hacker can do with remote RAT access

Remote administration tools, or RATs, lurk in phishing emails and malicious downloads across the internet. Once installed, they give hackers almost complete control over an infected machine. 

“Hackable?” host Geoff Siskind is always the hacked but in the latest episode, he gets to peek behind the curtain of a RAT attack and see just what hackers are able to do once they have remote access. Can they steal your files? See your webcam? Listen to your microphone?  

Listen now to the award-winning podcast Hackable? on Apple Podcasts. You don’t want to miss this eye-opening episode.  

 


The post Learn just what a hacker can do with remote RAT access appeared first on McAfee Blogs.

A New Year Means New Security Resolutions – Hear From the Experts

With January upon us, there’s undoubtedly a buzz in the air as security and development professionals eagerly plan out their 2019 strategies. You might be wondering what resolutions you can make that will help you navigate the New Year, and to take it a step further, what trends you should consider when crafting these resolutions. To help you get started, here are some suggestions from the Veracode team that will help you get a sense of what to expect in 2019 and have you on your way to a successful and secure year.

Sarah Gibson – Senior Application Security Consultant

Get your security and development teams collaborating and on the same page.

Good code is secure code, and having security help to design and build secure applications in a collaborative process allows for applications to be built better and faster. DevSecOps is a way to make that happen, and adopting a more automated and integrated approach between your security and development teams can make shipping secure code easier, with fewer last minute surprises.

Mark Curphey – Vice President of Strategy

Prepare for a boom in open source code use, and understand how to secure it.

Open source is now mainstream. We’re seeing it used in banking, autonomous cars, space travel, and even missiles, but as the community and commercial models for open source evolve, we’ll see a new realization that while you may get the code for free, you don’t always get security for free. How people continue to embrace open source code in light of that is still yet to be seen, but if you don’t want to be tomorrow’s news headline, you should be prepared with a game-plan of how to secure those components.

Chris Wysopal – Chief Technology Officer and Co-Founder

Prepare for the shift to serverless code, and turn your focus towards continuous security.

As more and more code moves to serverless, where there is no host or even container to configure, patch, and secure, the only thing left for organizations to secure will be their own code.

Code is increasingly becoming third party in the form of open source components and publicly available PaaS/SaaS APIs, which requires a supply chain security approach. With open source components, the public security posture of the components is taken into consideration to ensure that the least vulnerable version of a component is used, or – if necessary – a more secure component is used that has similar functionality. Supply chain security around PaaS/SaaS APIs is more challenging, but we see these providers publishing third-party reviews of their unique code, which open source components they use, and the security posture of the PaaS/SaaS APIs they used. The supply chain is becoming more public and more nested.

This will all be happening over a highly distributed set of microservices and APIs. These microservices will be developed using a DevOps methodology that will require continuous security. Newly developed code will be analyzed for weaknesses as it is written, and additionally analyzed as it is stitched into other code, and again as the context gets wider until a whole application or microservice is analyzed with its accompanying supply chain of open source components and PaaS/SaaS APIs.

Weaknesses will be transmitted to developers early, and the developers will be able to use suggested remediations, which will be reinforced by automated testing.

Maria Loughlin – Vice President of Engineering

Resolve to do something new, but just as important, resolve to continuously improve what you already do well.

You’ve probably been investing in automation for many years – automation of your testing, monitoring, metrics, and CI/CD pipelines. So in 2019, resolve to double-down on your automation investment to enable even more efficiency and quality consistency. In Veracode’s most recent State of Software Security report, we found a strong correlation between teams who have adopted a frequent, automated scanning approach and faster fix time for flaws.

To complement automation, turn your focus towards continuous security across all aspects of your organization, transforming your teams’ cultural mindset as well as in your pipelines and processes. It’s not realistic to hire a security expert for each scrum, so instead, resolve to train current team members to become security champions. Leverage their voices to represent the security perspective in each and every story prioritization, grooming, and review, and don’t be afraid to pull in security experts where needed. A nice side-effect of this practice is that investing in training for your team is proven to improve retention – a happy developer who is growing their career will stay in your organization.

Paul Farrington – Director of Solutions Architecture, EMEA & APAC

Continue to secure your software to mitigate against threats and avoid higher GDPR fines in 2019.

We are almost guaranteed to see more mega-breaches in 2019. Some of these will be undetected right now at time of writing, and may have been taking place for a number of months or years. The Marriott breach is a prime example of how serious an issue this is for large businesses. GDPR fines for breaches disclosed in 2018 are likely to top anything we have seen before when they are imposed in 2019 – in order to avoid being affected, organizations will need to continue to secure their software to mitigate against threats.

Everything You Need to Know to Kick-off and Mature Your Application Security Program

Whether you’re looking to measure the success of your application security program or want to know more about how you can mature your program in 2019, our “Everything You Need to Know” guides have you covered. Kick-start your journey to an advanced AppSec approach in the coming year by checking out the following:

Digging Up the Past: Windows Registry Forensics Revisited

Introduction

FireEye consultants frequently utilize Windows registry data when performing forensic analysis of computer networks as part of incident response and compromise assessment missions. This can be useful to discover malicious activity and to determine what data may have been stolen from a network. Many different types of data are present in the registry that can provide evidence of program execution, application settings, malware persistence, and other valuable artifacts.

Performing forensic analysis of past attacks can be particularly challenging. Advanced persistent threat actors will frequently utilize anti-forensic techniques to hide their tracks and make the jobs of incident responders more difficult. To provide our consultants with the best possible tools we revisited our existing registry forensic techniques and identified new ways to recover historical and deleted registry data. Our analysis focused on the following known sources of historical registry data:

  • Registry transaction logs (.LOG)
  • Transactional registry transaction logs (.TxR)
  • Deleted entries in registry hives
  • Backup system hives (REGBACK)
  • Hives backed up with System Restore

Windows Registry Format

The Windows registry is stored in a collection of hive files. Hives are binary files containing a simple filesystem with a set of cells used to store keys, values, data, and related metadata. Registry hives are read and written in 4KB pages (also called bins).

For a detailed description of the Windows registry hive format, see this research paper and this GitHub page.

Registry Transaction Logs (.LOG)

To maximize registry reliability, Windows can use transaction logs when performing writes to registry files. The logs act as journals that store data being written to the registry before it is written to hive files. Transaction logs are used when registry hives cannot directly be written due to locking or corruption.

Transaction logs are written to files in the same directory as their corresponding registry hives. They use the same filename as the hive with a .LOG extension. Windows may use multiple logs in which case .LOG1 and .LOG2 extensions will be used.

For more details about the transaction log format, see this GitHub page.

Registry transaction logs were first introduced in Windows 2000. In the original transaction log format data is always written at the start of the transaction log. A bitmap is used to indicate what pages are present in the log, and pages follow in order. Because the start of the file is frequently overwritten, it is very difficult to recover old data from these logs. Since different amounts of data will be written to the transaction log on each use, it is possible for old pages to remain in the file across multiple uses. However, the location of each page will have to be inferred by searching for similar pages in the current hive, and the probability of consistent data recovery is very small.

A new registry transaction log format was introduced with Windows 8.1. Although the new logs are used in the same fashion, they have a different format. The new logs work like a ring buffer where the oldest data in the log is overwritten by new data. Each entry in the new log format includes a sequence number as well as registry offset making it easy to determine the order of writes and where the pages were written. Because of the changed log format, data is overwritten much less frequently, and old transactions can often be recovered from these log files.

The amount of data that can be recovered depends on registry activity. A sampling of transaction logs from real world systems showed a range of recoverable data from a few days to a few weeks. Real world recoverability can vary considerably. Registry-heavy operations, such as Windows Update, can significantly reduce the recoverable range.

Although the new log format contains more recoverable information, turning a set of registry pages into useful data is quite tricky. First, it requires keeping track of all pages in the registry and determining what might have changed in a particular write. It also requires determining if that change resulted in something that is not present in later revisions of the hive to assess whether or not it contains unique data.

Our current approach for processing registry transaction files uses the following algorithm:

  1. Sort all writes by sequence number descending so that we process the most recent writes first.
  2. Perform allocated and unallocated cell parsing to find allocated and deleted entries.
  3. Compare entries against the original hive. Any entries that are not present are marked as deleted and logged.

Transaction Log Example

In this example we create a registry value under the Run key that starts malware.exe when the user logs in to the system.


Figure 1: A malicious actor creates a value in the Run key

At a later point in time the malware is removed from the system. The registry value is overwritten before being deleted.


Figure 2: The malicious value is overwritten and deleted

Although the deleted value still exists in the hive, existing forensic tools will not be able to recover the original data because it was overwritten.


Figure 3: The overwritten value is present in the registry hive

However, in this case the data is still present in the transaction log and can be recovered.


Figure 4: The transaction log contains the original value

Transactional Registry Transaction Logs (.TxR)

In addition to the transaction log journal there are also logs used by the transactional registry subsystem. Applications can utilize the transactional registry to perform compound registry operations atomically. This is most commonly used by application installers as it simplifies failed operation rollback.

Transactional registry logs use the Common Log File Sytstem (CLFS) format. The logs are stored to files of the form <hive><GUID>.TxR.<number>.regtrans-ms. For user hives these files are stored in the same directory as the hive and are cleared on user logout. However, for system hives logs are stored in %SystemRoot%\System32\config\TxR, and the logs are not automatically cleared. As a result, it is typically possible to recover historical data from system transactional logs.

The format of transactional logs is not well understood or documented. Microsoft has provided a general overview of CLFS logs and API.

With some experimentation we were able to determine the basic record format. We can identify records for registry key creation and deletion as well as registry value writes and deletes. The relevant key path, value name, data type, and data are present within log entries. See the appendix for transaction log record format details.

Although most data present in registry transaction logs is not particularly valuable for intrusion investigations, there are some cases where the data can prove useful. In particular, we found that scheduled task creation and deletion use registry transactions. By parsing registry transaction logs we were able to find evidence of attacker created scheduled tasks on live systems. This data was not available in any other location.

The task scheduler has been observed using transactional registry operations on Windows Vista through Windows 8.1; the task scheduler on Windows 10 does not exhibit this behavior. It is not known why Windows 10 behaves differently.

Transactional Registry Example

In this example we create a scheduled task. The scheduled task periodically runs malware.


Figure 5: Creating a scheduled task to run malware

Information about the scheduled task is stored to the registry.


Figure 6: A registry entry created by the task scheduler

Because the scheduled task was written to the registry using transacted registry operations, a copy of the data is available in the transactional registry transaction log. The data can remain in the log well after the scheduled task has been removed from the system.


Figure 7: The malicious scheduled task in the TxR log

Deleted Entry Recovery

In addition to transaction logs, we also examined methods for the recovery of deleted entries from registry hive files. We started with an in-depth analysis of some common techniques used by forensic tools today in the hopes of identifying a more accurate approach.

Deleted entry recovery requires parsing registry cells in hive files. This is relatively straightforward. FireEye has a number of tools that can read raw registry hive files and parse relevant keys, values, and data from cells. Recovering deleted data is more complex because some information is lost when elements are deleted. A more sophisticated approach is required to deal with the resulting ambiguity.

When parsing cells there is only one common field: the cell size. Some cell types contain magic number identifiers, which can help determine their type. However, other cell types, such as data and value lists, do not have identifiers; their types must be inferred by following references from other cells. Additionally, the size of data within a cell can differ from the cell size. Depending on the cell type it may be necessary to leverage information from referencing cells to determine the data size.

When a registry element is deleted its cells are marked as unallocated. Because the cells are not immediately overwritten, deleted elements can often be recovered from registry hives. However, unallocated cells may be coalesced with adjacent unallocated cells to maximize traversal efficiency. This makes deleted cell recovery more complex because cell sizes may be modified. As a result, original cell boundaries are not well defined and must be determined implicitly by examining cell contents.

Existing Approaches for Recovering Deleted Entries

A review of public literature and source code revealed existing methods for recovery of deleted elements from registry hive files. Variations of the following algorithm were commonly found:

  1. Search through all unallocated cells looking for deleted key cells.
  2. Find referenced deleted values from deleted keys.
  3. Search through all remaining unallocated cells looking for unreferenced deleted value cells.
  4. Find referenced data cells from all deleted values.

We implemented a similar algorithm to experiment with its efficacy. Although this simple algorithm was able to recover many deleted registry elements, it had a number of significant shortcomings. One major issue was the inability to validate any references from deleted cells. Because referenced cells may have already been overwritten or reused multiple times, our program frequently made mistakes in identifying values and data resulting in false positives and invalid output.

We also compared program output to popular registry forensic tools. Although our program produced much of the same output, it was evident that existing registry forensic tools were able to recover more data. In particular, existing tools were able to recover deleted elements from slack space of allocated cells that had not yet been overwritten.

Additionally, we found that orphaned allocated cells are also considered deleted. It is not known how unreferenced allocated cells could exist in a registry hive as all related cells should be unallocated simultaneously on deletion. It is possible that certain types of failures could result in deleted cells not becoming unallocated properly.

Through experimentation we discovered that existing registry tools were able to perform better validation resulting in fewer false positives. However, we also identified many cases where existing tools made incorrect deleted value associations and output invalid data. This likely occurs when cells are reused multiple times resulting in references that could appear valid if not carefully scrutinized.

A New Approach for Recovering Deleted Entries

Given the potential for improving our algorithm, we undertook a major redesign to recover deleted registry elements with maximum accuracy and efficiency. After many rounds of experimentation and refinement we ended up with a new algorithm that can accurately recover deleted registry elements while maximizing performance. This was achieved by discovering and keeping track of all cells in registry hives to perform better validation, by processing cell slack space, and by discovering orphaned keys and values. Testing results closely matched existing registry forensics tools but with better validation and fewer false positives.

The following is a summary of the improved algorithm:

  1. Perform basic parsing for all allocated and unallocated cells. Determine cell type and data size where possible.
  2. Enumerate all allocated cells and do the following:
    • For allocated keys find referenced value lists, class names, and security records. Populate data size of referenced cells. Validate key ancestors to determine if the key has been orphaned.
    • For allocated values find referenced data and populate data size.
  3. Define all allocated cell slack space as unallocated cells.
  4. Enumerate allocated keys and attempt to find deleted values present in the values list. Also attempt to find old deleted value references in the value list slack space.
  5. Enumerate unallocated cells and attempt to find deleted key cells.
  6. Enumerate unallocated keys and attempt to define referenced class names, security records, and values.
  7. Enumerate unallocated cells and attempt to find unreferenced deleted value cells.
  8. Enumerate unallocated values and attempt to find referenced data cells.

Deleted Recovery Example

The following example demonstrates how our deleted entry recovery algorithm can perform more accurate data recovery and avoid false positives. Figure 8 shows an example of a data recovery error by a popular registry forensics tool:


Figure 8: Incorrectly recovered registry data

Note that the ProviderName recovered from this key was jumbled because it referred to a location that had been overwritten. When our deleted registry recovery tool is run over the same hive, it recognizes that the data has been overwritten and does not output garbled text. The data_present field in Figure 9 with a value of 0 indicates that the deleted data could not be recovered from the hive.

Key: CMI-CreateHive{2A7FB991-7BBE-4F9D-B91E-7CB51D4737F5}\
     ControlSet002\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0019
Value: ProviderName  Type: REG_SZ  (value_offset=0x137FE40) (data_size=20)
     (data_present=0) (data_offset=0x10EAF68) (deleted_type=UNALLOCATED)

Figure 9: Properly validated registry data

Registry Backups

Windows includes a simple mechanism to backup system registry hives periodically. The hives are backed up with a scheduled task called RegIdleBackup, which is scheduled to run every 10 days by default. Backed up hives are stored to %SystemRoot%\System32\config\RegBack. Only the most recent backup is stored in this location. This can be useful for investigating recent activity on a system.

The RegIdleBackup feature was first included with Windows Vista. It is present in all versions of Windows since then, but it does not run by default on Windows 10 systems, and even when it is manually run no backups are created. It is not known why RegIdleBackup was removed from Windows 10.

In addition to RegBack, registry data is backed up with System Restore. By default, System Restore snapshots are created whenever software is installed or uninstalled, including Windows Updates. As a result, System Restore snapshots are usually created on at least a monthly basis if not more frequently. Although some advanced persistent threat groups have been known to manipulate System Restore snapshots, evidence of historical attacker activity can usually be found if a snapshot was taken at a time when the attacker was active. System Restore snapshots contain all registry hives including system and user hives.

Wikipedia has some good information about System Restore.

Processing hives in System Restore snapshots can be challenging as there may be many snapshots present on a system resulting in a large amount of data to be processed, and often there will only be minor changes in hives between snapshots. One strategy to handle the large number of snapshots is to build a structure representing the cells of the registry hive, then repeat the process for each snapshot. Anything not in the previous structure can be considered deleted and logged appropriately.

Conclusion

The registry can provide a wealth of data for a forensic investigator. With numerous sources of deleted and historical data, a more complete picture of attacker activity can be assembled during an investigation. As attackers continue to gain sophistication and improve their tradecraft, investigators will have to adapt to discover and defend against them.

Appendix - Transactional Registry Transaction Log (.TxR) Record Format

Registry transaction logs contain records with the following format:

Offset

Field

Size

0

Magic number (0x280000)

4

...

 

 

12

Record size

4

16

Record type (1)

4

20

Registry operation type

2

...

 

 

40

Key path size

2

42

Key path size repeated

2

The magic number is always 0x280000.
The record size includes the header.
The record type is always 1.

Operation type 1 is key creation.
Operation type 2 is key deletion.
Operation types 3-8 are value write or delete. It is not known what the different types signify.

The key path size is at offset 40 and repeated at offset 42. This is present for all registry operation types.

For registry key write and delete operations, the key path is at offset 72.

For registry value write and delete operations, the following data is present:

Offset

Field

Size

56

Value name size

2

58

Value name size repeated

2

...

 

 

72

Data type

4

76

Data size

4

The data for value records starts at offset 88. It contains the key path followed by the value name optionally followed by data. If data size is nonzero, the record is a value write operation; otherwise it is a value delete operation.

Top 10 Trending Keywords in .Com and .Net Registrations in December

With more than 300 million domain names registered globally, there are numerous examples of trending keywords reflected by domain name registrations. We have shown in the past that there is a correlation between domain name registrations and newsworthy and popular events, as well as anticipated trends.

Keeping in the spirit of the zeitgeist that .com and .net domain name registration trends can represent, Verisign publishes this monthly blog post series identifying the top 10 trending .com and .net keywords registered in English during the preceding month.

December 2018 TRENDING KEYWORDS

Here are the top 10 trending keywords registered in December 2018. Any surprises?

.COM

.NET

hemp hemp
divorce testing
pawn taxi
dentists strong
smiles friends
pilot  near
securities send
classifieds step
caviar europe
stable  california

 

Click here to see other domain trends blog posts, and make sure you check back the second Tuesday of each month for the latest keyword registration trends in .com and .net. Better yet, subscribe to the Verisign blog to have the posts delivered directly to your inbox.


Note: Each list was developed by examining keyword registration growth relative to the preceding month, such that those keywords with the highest percentage of registration growth are being reported on. This method is used to eliminate commonly registered keywords, such as “online” and “shop,” to provide a true look at monthly trends. In order to be included, a keyword must experience a minimum threshold in registration growth month over month. Qualifying keywords with the highest volume of registrations are then ranked and included in the list.

The post Top 10 Trending Keywords in .Com and .Net Registrations in December appeared first on Verisign Blog.

Happy 16th Birthday TaoSecurity Blog

Today, 8 January 2019, is TaoSecurity Blog's 16th birthday! This is also my 3,041st blog post.

I wrote my first post on 8 January 2003 while working as an incident response consultant for Foundstone.

Here are a few statistics on the blog. Blogger started providing statistics in May 2010, so these apply to roughly the past 9 years only.

As of today, since May 2010 the blog has nearly 9.4 million all time page views, up from 7.7 million a year ago.

Here are the most popular posts of the last 9 years, as of today:


I'm blogging a bit more recently, with 22 posts in 2018 -- more than my total for 2016 and 2017 combined, but still not half as much as 2015, which saw 55 posts.

Twitter continues to play a role in the way I communicate. Last year @taosecurity had nearly 49,000 followers with less than 18,000 Tweets. Today I have nearly 53,000 followers with 19,000 Tweets.

My rule is generally this: if I start wondering how to fit an idea in 280 characters on Twitter, then a blog post is a better idea. If I start a Twitter "thread," then I really need to write a blog post!

I continue to blog about martial arts and related topics at Rejoining the Tao, which incidentally will be three years old later this month, and is currently 11 posts shy of 100. You can see that during my burnout period I shifted my writing and creativity outside of security.

Thank you to everyone who has been part of this blog's journey since 2003!

How to Protect Three Common IoT Devices in 2019

It’s no secret – IoT devices are creeping into every facet of our daily lives. In fact, Gartner estimates there will be 20.4 Billion IoT devices by the year 2020. More devices mean greater connectivity and ease of use for their owners, but connectivity also means more opportunities for hacks. With CES 2019 kicking off this week, we turn our focus toward the year ahead, and take a look at some of the IoT devices that are particularly high-profile targets for cybercriminals: gaming systems, voice tech, routers, and smart cars.

Routers

Routers are very susceptible to attacks as they often come with factory-set passwords that many owners are unaware of or don’t know how to change, making these devices easy targets for hackers. That’s bad news, since a router is the central hub in a connected home. If a router is compromised and all of the devices share the same Wi-Fi network, then they could potentially all be exposed to an attack. How? When an IoT device talks to its connected router, the device could expose many of its internal mechanisms to the internet. If the device does not require re-authentication, hackers can easily scan for devices that have poorly implemented protocols. Then with that information, cybercriminals can exploit manufacturer missteps to execute their attacks. To help protect your router (and thus all your other devices), a best practice is to consider one with a layer of protection built-in, and be sure to use a long and complex password for your Wi-Fi network.

Gaming Systems

Over ten years ago, researchers found that many video gaming consoles were being distributed with major security issues involved with the Universal Plug and Play protocol (UPnP), a feature that allows IoT devices on a network to see each other and interact with one another. However, not much has been done to solve the problem. Through exploiting the UPnP weaknesses in gaming systems to reroute traffic over and over again, cybercriminals have been able to create “multi-purpose proxy botnets,” which they can use for a variety of purposes.  This is just the jumping-off point for malicious behavior by bad actors. With this sort of access into a gaming system, they can execute DDoS attacks, malware distribution, spamming, phishing, account takeovers, click fraud, and credit card theft. Our recent gaming survey found that 64% of respondents either have or know someone who has been directly affected by a cyberattack, which is an astonishing uptick in attacks on gamers. Considering this shift, follow our tips in the section above for routers and Wi-Fi, never use the same password twice, and be weary of what you click on.

Voice Tech

In 2018, 47.3 million adults had access to smart speakers or voice assistants, making them one of the most popular connected devices for the home. Voice-first devices can be vulnerable largely due to what we enable them to be connected with for convenience; delivery, shopping, and transportation services that leverage our credit cards. While it’s important to note that voice-first devices are most often compromised within the home by people who have regular access to your devices (such as kids) when voice recognition is not properly configured, any digital device can be vulnerable to outside attacks too if proper security is not set up. For example, these always-on, always-listening devices could be infiltrated by cybercriminals through a technique called “voice squatting.” By creating “malicious skills,” hackers have been able to trick voice assistants into continuing to listen after a user finishes speaking. In this scenario an unsuspecting person might think they’re connecting to their bank through their voice device, when unbeknownst to them, they’re giving away their personal information.  Because voice-controlled devices are frequently distributed without proper security protocol in place, they are the perfect vehicle in terms of executing a cyberattack on an unsuspecting consumer. To protect your voice assistants, make sure your Wi-Fi password is strong, and be on the lookout for suspicious activity on linked accounts.

While you can’t predict the future of IoT attacks, here are some additional tips and best practices on how to stay ahead of hackers trying to ruin your year:

  • Keep your security software up-to-date. Software and firmware patches are always being released by companies and are made to combat newly discovered vulnerabilities, so be sure to update every time you’re prompted to.
  • Pay attention to the news. With more and more information coming out around vulnerabilities and flaws, companies are more frequently sending out updates for smart cars and other IoT devices. While these should come to you automatically, be sure to pay attention to what is going on in the space of IoT security.
  • Change your device’s factory security settings. This is the single most important step to take to protect all devices. When it comes to products, many manufacturers aren’t thinking “security first.” A device may be vulnerable as soon as opening the box. By changing the factory settings you’re instantly upgrading your device’s security.
  • Use best practices for linked accounts.  For gaming systems and voice-first devices in particular, if you connect a service that leverages a credit card, protect that linked service account with strong passwords and two-factor authentication (2FA) where possible. In addition, pay attention to notification emails, especially those regarding new orders for goods or services. If you notice suspicious activity, act accordingly.
  • Setup a separate IoT network. Consider setting up a second network for your IoT devices that don’t share access to your other devices and data. Check your router manufacturer’s website to learn how. You might also consider adding in another network for guests and unsecured devices from others. Lastly, consider getting a router with built-in security features to make it easier to protect all the devices in your home from one place.
  • Use a firewall. A firewall is a tool that monitors traffic between an Internet connection and devices to detect unusual or suspicious behavior. Even if a device is infected, a firewall can keep a potential attacker from accessing all the other devices on the same network. When looking for a comprehensive security solution, see if a Firewall is included to ensure that your devices are protected.
  • Up your gaming security. Just announced at CES 2019, we’re bringing a sense of security to the virtual world of video games. Get in on the action with McAfee Gamer Security, Beta, it’s free!

Interested in learning more about IoT and mobile security trends and information? Follow @McAfee_Home on Twitter, and ‘Like” us on Facebook.

The post How to Protect Three Common IoT Devices in 2019 appeared first on McAfee Blogs.

Multisandbox project welcomes ReaQta-Hive

We are pleased to announce the addition of ReaQta-Hive to the multisandbox project, after the integrations of Tencent Habo, VirusTotal Droidy, Cyber adAPT ApkRecon, and Dr. Web vxCube. The unique new feature that this integration brings is XSL documents in addition to  PE files, PDF, MS Office documents and scriptlets.

In their own words:

ReaQta-Hive is an Endpoint Threat Response and Hunting platform that uses A.I. to detect new types of attacks. A live hypervisor, called the NanoOS, collects detailed security information at the lowest possible level of an endpoint, which Hive uses to perform dynamic behavioral analysis. This analysis is automatic and constructs a comprehensive storyline of an attack. The end result is an intuitive report of all the actions carried out by an attacker, including a summary of the meta-behaviors that highlight key components of the attack. ReaQta-Hive is a vector-agnostic platform, so it can analyze the behavior of any type of attack, whether it is file-less, script-based, exploit driven, or a plain executable file. We are happy to use our software and expertise to contribute actively to the VirusTotal community, and to help analysts worldwide be more effective and efficient.


To view the ReaQta report when viewing a file analysis, click on the Behaviour tab, select  ReaQta-Hivethen the detailed report.



In the detailed report, you can view copious amounts of information obtained by ReaQta-Hive:


Lets take a look at some example use cases where this data is interesting. 

XSL document  / #squiblytwo

This example is an interesting malicious XSL document which only ReaQta processes:
https://www.virustotal.com/#/file/9d3746779bc2b2d1ecbd90da8626f81978db4be1eb346106a6334295fce568cd/behavior 
In the relationships tab you can see a  link to VT Graph where you we can see some relationships to other domains and URLs VirusTotal has seen before.


 

Malicious document using LOLBins

Malicious code using Living off the land binaries and scripts (LOLBins) have become popular since they are binaries/scripts that are included with the operating systems, hence trusted. Here is a MS Office trojan that does so: 
https://www.virustotal.com/#/file/1f4f22f1814712880b2bbdc5c6418aeaf08c598be0990c5fad55136c9e769951/behavior 

 

Windows PE file, detecting behaviors like  key-logging/screenshots

    https://www.virustotal.com/#/file/d72f74208c8960ae70469af3968324c6d5f90a305931763c0f5e23cd7922bcea/behavior
      In the report we can see the detection and severity:


       

      MS Word document, executing powershell with emotet infection

        Behavior report:   
        https://www.virustotal.com/#/file/6dcd70d4e0d78a7aa12d8e4ae85d503fc7d642a9f5e950f43803c3471753ab6e/behavior
          Viewing in VirusTotal Graph, we can expose the network infrastructure involved. 



             

            Malicious Document dynamic impersonation, then drops keylogger 

            Take a look at the ReaQta detailed behaviour report linked from the VT page at:
            https://www.virustotal.com/#/file/24d94671e38f8f2f4c2f158e011a24c4641994b14962b3c4343308efdfb8fa71/behavior


            dynamic process impersonation icon
            Within the process tree, you'll notice the process-hollowing (dynamic process impersonation) icon:

            This also shows up in the "INJECTED PROCESSES" section of the report:


            In the VT Graph we can see the relationship to the DDNS host and keylogger that is dropped.



             

            Windows Scriptlet (SCT) file 


            In the file https://www.virustotal.com/#/file/f128a63c107c3006ebf448d6ec743d11eb491ecb508e4ce63ba084f9792c25da/details we see a scriptlet file dropping a miner.

            Have a look yourself by checking out the behaviour tab:






            No, Spotify Wasn’t Hacked

            Presently sponsored by: Live Workshop! Watch the Varonis DFIR team investigate a cyberattack using our data-centric security stack

            No, Spotify Wasn't Hacked

            Time and time again, I get emails and DMs from people that effectively boil down to this:

            Hey, that paste that just appeared in Have I Been Pwned is from Spotify, looks like they've had a data breach

            Many years ago, I introduced the concept of pastes to HIBP and what they essentially boil down to is monitoring Pastebin and a bunch of other services for when a trove of email addresses is dumped online. Very often, those addresses are accompanied by other personal information such as passwords. When an HIBP subscriber's address appears in one of these incidents, they get an automated notification and often, it seems, they then reach out to me.

            Here's a perfect example of what I'm talking about, this one eventually triggering an email to me just last week:

            No, Spotify Wasn't Hacked

            Let's imagine you're the first person on the list; you get a notification from HIBP, you check out the paste and see your Hotmail account listed there alongside your Spotify password and the plan you're subscribed to. Clearly a Spotify breach, right?

            No, and the passwords are the very first thing that starts to give it all away. Just looking at them, they're obviously terrible, but plugging the first one into Pwned Passwords give you a sense of just how terrible it is:

            No, Spotify Wasn't Hacked

            They may not all be that bad (the next one in the list has only been seen twice), but the point is that it's a password that's clearly been seen before and were I to dig back into the source data, there's a good chance it's been seen in a breach alongside that email address too. Then there's the fact that the password is in plain text and I don't know precisely how Spotify store their passwords, but it'd be a very safe bet that by now it's a decent modern-day hashing algorithm. If they had a breach then yes, hashes may be cracked, but that's not what's happening here.

            We're simply seeing the successful result of credential stuffing attacks. Regular readers will appreciate the mechanics of this already but all those who I point here for whom this is new, this attack simply takes exposed credentials from a data breach and tries them on another site. The attack is simple but effective due to the prevalence of password reuse. If you were using the same password on LinkedIn when they had their data breach as you are on Spotify today and someone grabbed that password from the breach and tried it on Spotify, you can see the problem. That's it, job done, they're into your account.

            Spotify "breaches" like this are enormously common. I just went and looked at the pastes HIBP has collected since the clock ticked over to 2019 and found 20 of them already:

            No, Spotify Wasn't Hacked

            Digging further, I found over a thousand pastes with "Spotify" in the title. These are often removed by Pastebin pretty quickly but looking through some that remain, it's precisely the same pattern as the earlier example. I grabbed a random email address out of one of them and checked it on HIBP:

            No, Spotify Wasn't Hacked

            The same address appears over and over in pastes and each time, the same password appears alongside it. Picking one from the list above that hasn't yet been removed shows a page full of examples like this (with a password Pwned Passwords has seen 4 times before):

            No, Spotify Wasn't Hacked

            This one is interesting for a couple of reasons and the first is the use of the term "combo". I've written about combo lists before and they're essentially combinations of email addresses and passwords used to test against services in credential stuffing attacks. Thousands. Millions. Billions of them, in some cases. The second interesting observation in that image is the "Spotify Cracker" reference. The first Google result for the term shows a popular cracking forum with the following image (password seen 447 times in Pwned Passwords):

            No, Spotify Wasn't Hacked

            This is a tool for breaking into Spotify accounts I wouldn't normally link through to content of that type, but context is important. For people wondering why they're getting alerts from HIBP because their Spotify account is in a paste somewhere, have a flick through some of those pages. 61 of them at the time of writing, each with 20 posts thanking the OP for their work in order to get access to the tool. So what does it do? Have a quick watch of this:

            It's a slightly different piece of software based on what's visible, but the objective is the same and the premise is simple: download the tool, pass in the combo list then let it run. Credentials from the list are then tested against Spotify (yes, security friends, there's a very good question to be asked here as to why this is still possible...) and results appear on the screen.

            Now, this isn't to say that someone who finds their Spotify account on one of these lists shouldn't worry because it wasn't a breach per se. Instead, they need to look inwardly and adjust their own security practices instead. Get a password manager (8 years on and I still use 1Password every day), create strong and unique passwords on every account and enable 2-factor authentication where available. Well, except that there's still no 2FA support on Spotify so just enable it on every other service that supports it (and most big ones do these days).

            And why would someone "hack" (I use the term loosely because they literally logged in with the correct username and password) Spotify accounts? The obvious answer is that they have a monetary value, but I also posit that it's very often just curiosity driving this behaviour. Take a look at a video such as this SQL injection tutorial; I've used it in talks before to illustrate the randomness of attacks as well as the sophistication of those behind many of them. Is the person in this video an evil cyber hacker hell-bent on causing chaos, or just a curious kid whose moral compass is yet to be properly calibrated? That may not make Spotify users feel any better about the end result, but it's important context for this post.

            In doing a bit of searching for this piece I found heaps of results for "spotify data breach" that led to discussions highlighting what I've covered above. For example, this one from August on the Spotify community site where the original post begins with:

            Someone had access to my pasword [sic] (which is totally unbreakable and diferent [sic] from the one i use in other accounts)

            I don't know what their password was, but I do know that I've had dozens of discussions with people making precisely the same claims only to discover "their" password is in Pwned Passwords a few hundred times! Or they entered it into a phishing site somewhere. If we apply Occam's Razor to this (the simplest solution is the most likely one), the password was compromised. I want to illustrate this point via the following Tweet:

            This is Scott Helme, a world-renowned security researcher who understands these concepts as well as anyone I can imagine. This tweet is part of a broader discussion where his Pinterest account was logged into by an unknown party and per the image above, Scott was convinced his password was both strong and unique. A couple of hours later, Scott's view is, well, somewhat "different":

            I spoke to Scott about this incident again whilst writing this post and we both reflected on just how easy it is to have issues like this, even you're convinced your security is spot on. It's precedents like this which cause me to pause and question every strongly made claim of personal security prowess in the wake of examples such as the Spotify community one above.

            Reading through that thread only reinforces the view that this was a simple account takeover issue and not a sophisticated hack. For example, this comment:

            It's such a shame to see Spotify blaming its users for getting hacked instead of fixing the problem. Got my playlists deleted and the hacker created a playlist called "Get Hacked".

            Imagine you're a hacker - a real one with the capabilities to break into a company with hundreds of millions of users and worth billions of dollars - what are you going to do? Are you just going to mess with people's playlists "for the lulz"? No, at the very least you're going to cash in on their public bug bounty or if you're really the malicious type, you're going to monetise their users in a much more surreptitious fashion.

            Scroll down a little further and someone is referencing HIBP as "proof" of a hack. Here's what happened to the guy's account:

            I got a notification from haveibeenpwned.com and did nothing about it until some random kept playing weird music on a device I did not recognize while I was trying to listen on my normal device. It was annoying, I kept getting pulled out of my song because we started battling for control of what device and what song the audio was to be heard on. I started playing really loud and obnoxious noise music for the hacker while I changed my password.

            Now again, let's apply Occam's Razor: is this an elite hacker who's discovered some previously unknown zero-day vulnerability, or someone who's exploited the victim's password and then simply has a different taste in music?

            The community thread references a paste titled "Más de 300 cuentas premium de Spotify" ("More than 300 Spotify premium accounts") which has since been deleted from Pastebin (and HIBP doesn't save the contents beyond just the email addresses). But 4 days earlier there was a paste titled "Más de 50 cuentas premium de spotify" which still stands today and its content lines up very closely with the others discussed above; it's simply the output of another automated tool exploiting weak credentials.

            I'll end on one final point because if I don't, it'll come through in the comments anyway: online security is a shared responsibility. Some people are quick to play the "victim blaming" card when I write about incidents that can be traced back to weak security practices. Clearly, that's not causing me to sugar-coat the root cause of these incidents but that said (and I touched on this earlier), this is prevalent enough that Spotify also needs to look internally at why this is still occurring. Their job is to stop this form of attack at the platform level and our job as users of the service is to protect our accounts via some basic security practices.

            So no, Spotify wasn't hacked, they just allowed malicious parties to log in with other people's poor passwords.