WTH? DPRK IT WFH: Justice Department says N. Korean hackers are getting remote IT jobs, posing as Americans.
The post North Korea IT Worker Scam Brings Malware and Funds Nukes appeared first on Security Boulevard.
Hackers can find templates for DocuSign and other companies for their phishing campaigns on dark web marketplaces for as little as $10.
The post Hackers Use Fake DocuSign Templates to Scam Organizations appeared first on Security Boulevard.
One in three office workers who use GenAI admit to sharing customer info, employee details and financial data with the platforms. Are you worried yet?
The post Risks of GenAI Rising as Employees Remain Divided About its Use in the Workplace appeared first on Security Boulevard.
Phish Ahoy! Hacker took advantage of Dell’s lack of anti-scraping defense.
The post Dell Hell Redux — More Personal Info Stolen by ‘Menelik’ appeared first on Security Boulevard.
I am already making you better at phishing.
Right now.
How could that be possible? Please, don’t worry about specifics right now. Just trust that I am making you better at phishing.
Why would I be so selfless to boost your phishing skills free of charge? Again, you don’t need to know. Just know that this is our agreement: you keep reading my words, and I will make you better at phishing. Nay. Great at phishing! It will only hurt a little, but the pain will be well worth it. Sounds like a bargain? Then welcome to my school of phish! Now please open your textbooks to lesson number 1…
If you’ve done penetration testing for any extended length of time, you’ll regularly hear the phrase, “no one likes phishing” in regards to client requests to perform social engineering as part of a penetration test or red team operation.
For many, this request always seems to entail the mind-numbingly banal task of setting up phishing infrastructure, choosing a pretext scenario, testing the scenario, and crossing your frustrated fingers in the hopes that you’ll dupe someone into clicking a malicious link. The overall approach is blunt, half-hearted, and can leave you feeling either guilty for ruining someone else’s day or just downright bored.
Here are some other general gripes I’ve heard from my fellow pen-testers regarding phishing:
These are all valid points, and I’ve probably used each of these arguments myself on multiple occasions to either explain to my boss or client why we shouldn’t do phishing. However, I would like to challenge you with a simple question:
Let’s assume your phishing attempt is actually successful. Some poor unsuspecting target clicked your link or file, you delivered a payload that called home and you just got the alert that you have a shell. On a scale from, “Ugh. This is so boring! I’ll just take my lunch break and deal with this later…” to, “Holy crap! It worked! I’m going to dance around the office and look for someone to high five!”, how do you feel?
If an outside observer saw your reaction to getting an “organic” shell, they might be fooled into thinking you really like phishing. They may even think you …love… it?
If you are in the right industry, you love shells, and you better be honest with me that you feel like a beast when you cede access for yourself. So…does everyone hate phishing? Not really! In fact, most of us may like it a thousand times more than we think we do! When we say we “hate phishing,” that’s only because we don’t want to admit something else:
What we actually hate is losing!
Penetration testing isn’t a game, but it can still “feel” like it is and it’s extremely hard to let go of that feeling. We also want to do a good job and if our phish fries and dies versus catching the target hook, line, and sinker; it can feel like we’ve done a bad job. And here’s the worst part: I know it hurts to hear, but if you “hate phishing”, it’s most likely because your phishing campaigns suck. That may sting a little, but please just let that sink in for a minute. Let’s use that feeling as motivation to improve.
If you are completely new to penetration testing, a dead in the water phishing attempt may not even be your fault. You were likely thrown into the deep end without any formal training (or worse: had a bad teacher and only learned some bad or outdated techniques). However, in a field of highly curious self-learners, I think that “I’m a complete guppy at this” has limited reach. At some point, we need to face the fact that most phishing campaigns don’t work because we don’t put the same level of effort into them as we do post-exploitation. If you’re still with me at this point, let’s talk about how we as a “grouper” can do better.
Yes, winning at phishing is hard, but it’s a lot easier than evading the latest ERD/XRD/AI endpoint defenses; so don’t kid yourself into thinking you can’t do it. As red teamers, we bypass endpoint defense products every day and many of the same methodologies and techniques we use to bypass those products can be applied to bypass email security as well.
Often, it’s the unknowns that bug us the most when it comes to failed phishing attempts. There are multiple steps that all have to go right to have a successful phishing campaign. To give ourselves the best chance of success, we need to identify potential failure points and address each one. Let’s drag all of these lurking failure points out into the light where we can see and analyze them:
I find it helpful to conceptualize these common failures by grouping them into the following buckets:
Message Inbound → User Outbound → Payload Inbound → C2 Outbound
It’s hard to deliver payloads and collect sensitive data using nothing but email. In most cases, you’ll need to entice our phish out into open waters where we have the advantage. You then have a great deal of flexibility in how you exploit your target, but you need to ensure each link in the chain succeeds; otherwise, it’s just bad bait.
The overall probability of the success of a phishing campaign is the product of each of the probabilities of success of each of these steps:
Good User% × Reputation% × Content% × Click Through Rate% × Link Allowed% × …
The Bad News:
Unfortunately, this means a low probability on a single item could completely wreck your overall probability rate if the target organization is doing even the bare minimum for that control. If you fail to take into account one of these controls, you’re likely to be doomed with bad phishing success rates (and may need to do a little “fine tuna-ing” to get another bite).
The Good News:
Conversely, if you look at the list, and realize you have not even been attempting to circumvent a particular control, then applying any best-guess approach to boosting your probability in that one area will likely drastically improve the overall probabilities of success for all of your phishing campaigns compared to your current approach. If you then actually test and measure the effectiveness of your control bypasses, you can achieve high probabilities in all areas.
Steps 2 through 5 are often, but not always, a black hole from our perspective. We don’t know the email hit an inbox until our phishing links generate some visible traffic. Even then, it could just be a bot checking the link before delivering the message to a target. However, we can get hints about which steps succeeded and which failed if we collect the right data.
When looking at the task from this perspective, it should hopefully look less daunting. If I challenged any seasoned red teamer to bypass any individual control/issue on the list, they would likely solve it within hours and possibly in multiple ways. If we then find bypasses that work well for us, we can weaponize and streamline the deployment of our techniques. This is no different than collecting known bypasses for various endpoint protections.
For now, follow me in the next blog where we will dive in to Message Inbound Controls with how to collect a good targets list:
Phish Sticks; Hate the Smell, Love the Taste was originally published in Posts By SpecterOps Team Members on Medium, where people are continuing the conversation by highlighting and responding to this story.
The post Phish Sticks; Hate the Smell, Love the Taste appeared first on Security Boulevard.
A weapon is useless unless you have something to aim it at. When we weaponize social engineering, our targets are the humans who have the ability to give us access to the systems and data we want to compromise. In this post, we’ll explore ways to find target users for our phishing campaigns. We’ll then talk about what makes a “good” target vs. a “bad” target.
When looking for the “right” targets, our general approach will be to collect as many potential contacts as possible and then pair down the list based on what we can learn about each individual.
Before diving into contact collection, we want to make sure that we have a clear picture of the available attack surface. I’ve seen many pentesters take only the main domain the client supplied, run it through theHarvester, linkedInt, maltego, etc. and call the output a targets list. In doing so, these pentesters completely overlooked valuable attack surfaces associated with the target organization’s other domains. We can do better. Here are some of my favorite ways to find our target’s other domains:
When you register a domain, you have to fill out some basic contact information like the organization name and “abuse email” for the WHOIS service. While you can technically put anything you want, and most registrars offer a WHOIS anonymizing service, many organizations still fill out the form with identifiable information. This means that we can often cross-reference WHOIS contact information and find associated domains.
Unfortunately, the WHOIS protocol was never intended to allow lookups based on contact information; however, there are paid APIs like Whoxy and WhoisXML that have indexed millions of WHOIS records and made them searchable. Whoxy is a nice quick check because its API credits are insanely cheap; however, its search functionality is case sensitive and they do not have the same coverage as WhoisXML.
Of course, the WHOIS protocol is a very simple, text-based, call-and-response protocol. With a little scripting and distributed computing, we could pretty easily mine and index our own data as well. If you decide to go this route, keep in mind that many WHOIS providers expressly forbid data mining. You’ve been warned!
If your target organization uses AzureAD, then you can use the autodiscover service to get a list of all of their tenant’s domains. Dr. Nestori Syynimaa released a great tool and blog post that covers this method:
Just looking: Azure Active Directory reconnaissance as an outsider
When organizations set up a website on a domain, they will often add a link back to their main domain somewhere on the website. In the SEO world, these are referred to as “backlinks”. You can use free SEO tools online to enumerate these links and look for any domains you missed with other methods. You will also often see backlinks from other organizations that do business with your target organization. Take note of these as you find them, as we might be able to abuse an implicit trust between these organizations when crafting our campaigns.
Once we have a list of associated domains, we should do a quick sanity check to find out which ones have a published MX record. There is no use enumerating email addresses for a domain that doesn’t even have a mail server. This is to make sure we don’t waste time or API credits during email collection:
dig mx -f domains.txt | grep ANSWER -A 1 | grep MX
Now that we have a list of associated domains, we can search for contacts at (@) each one. In the next sections, we are going to cover a range of contact collection methods starting with the well-known and simple (little phish) and working up to the more obscure and difficult (bigger phish).
While most of these methods are focused on obtaining email addresses, some of them will also give you phone numbers and mailing addresses. Don’t overlook this extra data! You can call phone numbers to see if they are direct lines and check if the target is still employed at the organization. We can also deliver payloads over the phone or even via snail mail if we have to. Likewise, if your data source includes information like job titles, grab this information too. It could be useful when pairing down our list.
Read the website: This is a (hopefully) obvious first step, but you might be surprised by the number of times I’ve seen pentesters skip it. On more than one occasion, I’ve found an employee directory on the main website after hearing co-workers complain about “not finding any email addresses” with OSINT tools.
Google dorks: Along the same lines, it’s worth a quick Google search to see if there are any employee listings that are not hosted on the main website. There are plenty of OSINT tools that can even automate some common dorks for you. Try using Google to find some ;)
theHarvester/Skiddy Scripts: While I haven’t used theHarvester in a while now, I was pleasantly surprised to see that it is still being actively maintained as of 1/1/24. The reason I don’t currently use it is because I tend to view tools like this as just a wrapper for their data sources. If you like using a particular email mining OSINT tool, by all means keep using it. Though I would challenge you to at least peek under the hood to see how your favorite scripts work, and familiarize yourself with where the data comes from.
LinkedIn Mining: LinkedIn (LI) is a great source for employee names, positions, departments, and other useful target data we can collect in a variety of ways. If you’ve never built your own LinkedIn miner, I would highly recommend it as an exercise. The skills you learn can be applied to mining other OSINT sources as well:
LI Mining (Beginner): Go to the target organization, click on their employees, and copy-pasta each page. Next, grep/cut/sed foo to get your results. Taking this a step further, you can write a JavaScript one-liner to select the elements you want to mine and print them to the developer console and speed up the process significantly.
LI Mining (Intermediate): Use BurpSuite or Zap Proxy to intercept your traffic while navigating LI. Next, write a script to replicate the API calls used to retrieve user records. Conversely, just use one of the many existing tools that already do the same thing (LinkedInt, AttackSurfaceMapper, etc.).
LI Mining (Advanced): Use a framework like Puppeteer to write a bot that mines each page for you. Keep in mind that when you navigate to a page of employees, there will only be a few on the page until you scroll down. Scrolling to the bottom of the page triggers an AJAX request to grab the rest of the user records for that page. Then have the bot wait a second or two for the results to populate and inject some JavaScript (possibly from your ‘beginner’ script above) to mine the useful data. While this may seem like a lot of work, the overall advantage is that, when done correctly, you can build a bot that mimics a human using the site and potentially extend the useful life of your account. Obvious attempts to mine data can result in having your account locked. If you would like to take this approach, keep in mind that Puppeteer (and other automation frameworks) default settings include things like an obvious user agent string that will definitely get you burned, so do your research.
Note on LI Connections: For any of these methods to be fruitful, you will need first and second connections with your targets. It’s worthwhile to log into your OSINT account and connect with various users at your target organization well in advance of your test. If you have the budget, another option is to pay for “LinkedIn Sales Navigator” to skip all the organic connections and get unfettered access to search your targets.
Hunter.io and Zoominfo: These websites are all about finding marketing leads at companies. If you think about it, cold emailing is basically the exact same thing as phishing. Online marketing is all about finding the right people in the target organization to interact with your message. Online marketers face many of the same challenges as we do, and therefore, good marketing tools can be extremely useful for setting up phishing campaigns. Both of these sites will give you a few free search results and also have paid search APIs. One of the things I love about Hunter.io is that you get the URL where each contact was found on the Internet. This will often lead you directly to employee directories where you can mine more contacts.
phonebook.cz: This is a tool with a great free tier that is meant to highlight the power of intelx.io’s database. The service used to be completely open, but now requires you to register an account to limit abuse. The search is still completely free.
Dehashed: This tool is a searchable aggregation of a large number of public data breaches. If employees of your target organization used their work email for any of these breached services, you get their work email address at a minimum, and frequently get passwords, full names, usernames, and other potentially useful data. It’s a paid API, but the pricing is quite reasonable. I’ve had a few engagements where social engineering was not even necessary because we found valid passwords credential stuffing with Dehashed results.
It’s generally a good idea to learn a little bit about your target organization’s industry and if there are any data sources you can mine that might have names and contacts for potential targets. Here’s just a few examples.
Rate My Professor — If you happen to be pentesting a client in higher education, you can often get a good list of current employees from Rate My Professor. The API is simple and easy to mine. Students crowdsource the data and keep it up-to-date.
Nationwide Multistate Licensing System (NMLS) — If your client is a bank, credit union, or other financial institution, you can often find contact information for loan officers through the NMLS. You also have the added benefit of identifying a sub-group within the organization that might respond well to certain pretexts pertaining to loans.
CPAVerify — Most large organizations have full-time accounting staff and many of them are certified! When CPAs renew their license each year, they have to fill out contact information including their current employer. There are free sites to “verify” CPA licenses and many of them support searching company names. If you really want to ruffle some feathers, send a phish to the CPAs saying they might be losing their license just before tax season. I know this works well because an overzealous pentest team did it to my previous employer (a large accounting firm), and got themselves fired for causing too much of a disruption.
Call them and ask for a directory!: Social engineering, when done well, is often an iterative process. You get some access, mine some useful data, and use it to target another user with more access. If you’re struggling to find contacts, it’s worth a shot to just call anyone in the organization, impersonate a new employee, come up with a sob story about how you’re trying to reach people on your team but can’t find the employee directory, and see if they’ll email a copy to your Gmail account. While it might be an odd request, it likely won’t raise suspicion as much as asking them to tell you their password or go to some sketchy website, and most people will take the time to help out a fellow employee. This isn’t exactly “hard” as much as it is uncomfortable, but is well worth the payoff when it works.
Mine the internet yourself: If API limits are cramping your style, or the APIs you are searching don’t have the data in a format that works well for you, then why not just build your own OSINT database? CommonCrawl is a massive open source repository of web crawl data from a sizable portion of the web. Their website features lots of cool projects that showcase how to use the dataset to mine interesting stuff.
Common Crawl - Example Projects
You can mine emails and associated URLs from the dataset to build your own OSINT database. For example, you can modify the open source tool WARCannon to ‘grep the Internet’ for email addresses, and then use ElasticSearch to index your results:
GitHub - c6fc/warcannon: High speed/Low cost CommonCrawl RegExp in Node.js
If you want to take it a step further, you can use AWS Lambda for Rust to do the same thing on a very low budget. If you space out the processing a bit, you can even do it all on the free tier.
Stealer logs: A “stealer” is a form of malware used to continually harvest user data like email addresses, account names, and passwords from an infected host. Operators who write and distribute this type of malware often take an opportunistic approach and simply try to infect as many systems as possible, amassing data from hundreds of thousands of systems. Some of these “stealer logs” have been leaked and contain a massive amount of user data. If an employee at your target organization happens to have been a victim of one of these trojans, then that data can be very useful on a pentest. Unfortunately, to make these breaches useful, you will have to normalize and index large volumes of loosely structured data yourself.
The Global Address List (GAL): If you happen to compromise access to a user’s o365 account, then you can use the GAL to pull contact information for everyone in the tenant. This can be done directly from the developer tab in the browser:
https://medium.com/media/7cff880f2402de320ee1e7aed48654fe/href
It’s not exactly a backdoor, but it does greatly increase your chances of gaining another foothold if your access is lost. Like asking for an employee directory, this is another technique we can use to perform iterative social engineering to go after more privileged access once we compromise a single user.
Once we have a list of contacts, we should pair down the list into groups of targets that might be susceptible to various pretexts. This step is all about increasing our success rate as defined by the ratio of clicks to emails sent. Ideally, we would find a single, highly-susceptible target, and send a single email with a success rate of 100%. Of course, we have no way to measure susceptibility ahead of time, so we will have to make best guesses instead. We will do this based on some generic traits that we tend to see in common between “good” (high success rate) targets and avoid targets with traits commonly associated with low success rates.
If we just spent all this time mining contacts to maximize our potential blast radius, then why wouldn’t we just phish everyone? Wouldn’t that give us the highest chance of success?
If we only plan to send a single pretext, then the answer is yes. Exposing every target to the chosen pretext will maximize our chance of success, but there is a major flaw to this approach: If we want to phish everyone, then we are going to need an extremely generic pretext. These generic phishing messages will only work against the lowest common denominator (most susceptible) targets and will be easily recognized as a phish by everyone else. Compared to more targeted pretexts, generic pretexts have a very low click-through rate while overexposing the campaign to incident responders potentially discovering them.
Instead, I have found that we can more consistently craft scenarios with click-through rates over 50% when we take the approach of targeting either individuals or small groups of targets with similar job positions and interests. My goal is always to identify at least a few small groups of employees to target with specific pretexts. With a very convincing pretext, we may be able to obtain a foothold with only 3–5 total target interactions.
Online Presence — The more we know about a target, the more likely we will be able to come up with a pretext they will believe. Simply having a lot of available information online for a particular user makes them a potentially good candidate for spear phishing.
Bad Hygiene — When I see cases of employees using their company email as a personal contact or posting questions on forums with identifiable usernames, I know I have a good target. People who like to use their company email for “everything” frequently get personal emails on their work device. This opens up a whole new set of potential pretexts that often have a high success rate. You might also find cases of employees who like to “put themselves out there” online, which means these individuals are frequently responding to unsolicited emails from strangers.
Check-the-Box Worker — In my experience, it seems that there are a couple of workflow types that tend to leave certain workers susceptible to phishing more so than the average user. One of those types is what I’ll refer to as a “check-the-box” work style. Individuals whose main objective each day is to accomplish as many tasks as possible from their queue can often rush through tasks so quickly that they miss the telltales of a phish when a little social engineering is thrown into the mix.
Customer-Pleasing — If sales and customer support teams are taught that the “customer is always right” or similar rhetoric, they may be overly trusting of outside requests. While most of their interactions with customers are legitimate and benign, they could be tripped up when a malicious request comes in.
Guppies — New employees who have not yet been thoroughly trained on the company’s security policies and procedures, and have less knowledge of how a typical interaction or request is “supposed” to look, are inherently more susceptible to all forms of social engineering. Go look at your LinkedIn results to see how long each employee has been with your target organization.
Now that we know how to identify good targets, we can also identify bad targets as ones that either lack “good” qualities, or exhibit an opposite trait:
Just an email — If we can’t mine any additional context about the human behind the address, we have no clue what types of pretexts might be useful against that target.
Rarely works with others — People who do most of their job solo tend to question any random request that is sent their way, whether it’s legitimate or not. Beware of being pushy with these skeptics.
Senior Executives and IT Staff (A.K.A. Whales) — While successfully phishing one of these users is typically going to get you privileged access right away, your overall chance of success is very low with this group. If you want to go whaling for the bragging rights, go right ahead, but just know that this is not a repeatable approach. When going after initial access, we will have more consistent success targeting other groups.
Plenty of Phish in the Sea was originally published in Posts By SpecterOps Team Members on Medium, where people are continuing the conversation by highlighting and responding to this story.
The post Plenty of Phish in the Sea appeared first on Security Boulevard.
Будет! Russian ransomware rascals riled a Roman Catholic healthcare organization.
The post FBI/CISA Warning: ‘Black Basta’ Ransomware Gang vs. Ascension Health appeared first on Security Boulevard.
Source: securityboulevard.com – Author: Jeffrey Burt Dell is sending emails to as many as 49 million people about a data breach that exposed their names, physical addresses, and product order information. According to the brief message, bad actors breached a Dell portal that contains a database “with limited types of customer information related to purchases […]
La entrada Dell Data Breach Could Affect 49 Million Customers – Source: securityboulevard.com se publicó primero en CISO2CISO.COM & CYBER SECURITY GROUP.
Source: www.techrepublic.com – Author: Fiona Jackson TechRepublic consolidated expert advice on how businesses can defend themselves against the most common cyberthreats, including zero-days, ransomware and deepfakes. Today, all businesses are at risk of cyberattack, and that risk is constantly growing. Digital transformations are resulting in more sensitive and valuable data being moved onto online systems […]
La entrada How Can Businesses Defend Themselves Against Common Cyberthreats? – Source: www.techrepublic.com se publicó primero en CISO2CISO.COM & CYBER SECURITY GROUP.
The tech giant says the information stolen doesn't represent a significant risk to users, but cybersecurity experts disagree.
The post Dell Data Breach Could Affect 49 Million Customers appeared first on Security Boulevard.
Source: securityboulevard.com – Author: Jeffrey Burt A group of bad actors — likely from China — is running a global cybercrime-as-a-service operation. It oversees a massive network of fake shopping websites that has conned more than 850,000 people in the United States and Europe into purchasing items, over the past three years, and the organization […]
La entrada Massive Online Shopping Scam Racks Up 850,000 Victims – Source: securityboulevard.com se publicó primero en CISO2CISO.COM & CYBER SECURITY GROUP.
Chinese crooks are running a global network of more than 75,000 fake online shops to steal credit card data and process fraudulent payments.
The post Massive Online Shopping Scam Racks Up 850,000 Victims appeared first on Security Boulevard.
PAFACA SueTok: U.S. Courts “likely” to rule whether new law is constitutional—or even practical.
The post TikTok Ban — ByteDance Sues US to Kill Bill appeared first on Security Boulevard.
The centralized system helps organizations identify, track, and reduce risks, addressing the challenges of incomplete risk visibility and manual processes.
The post Critical Risk Launches Critical Start Cyber Risk Register appeared first on Security Boulevard.
Scammers tricked a company into believing they were dealing with a BBC presenter. They faked her voice, and accepted money intended for her.
Interesting social-engineering attack vector:
McAfee released a report on a new LUA malware loader distributed through what appeared to be a legitimate Microsoft GitHub repository for the “C++ Library Manager for Windows, Linux, and MacOS,” known as vcpkg.
The attacker is exploiting a property of GitHub: comments to a particular repo can contain files, and those files will be associated with the project in the URL.
What this means is that someone can upload malware and “attach” it to a legitimate and trusted project.
As the file’s URL contains the name of the repository the comment was created in, and as almost every software company uses GitHub, this flaw can allow threat actors to develop extraordinarily crafty and trustworthy lures.
For example, a threat actor could upload a malware executable in NVIDIA’s driver installer repo that pretends to be a new driver fixing issues in a popular game. Or a threat actor could upload a file in a comment to the Google Chromium source code and pretend it’s a new test version of the web browser.
These URLs would also appear to belong to the company’s repositories, making them far more trustworthy.
After the XZ Utils discovery, people have been examining other open-source projects. Surprising no one, the incident is not unique:
The OpenJS Foundation Cross Project Council received a suspicious series of emails with similar messages, bearing different names and overlapping GitHub-associated emails. These emails implored OpenJS to take action to update one of its popular JavaScript projects to “address any critical vulnerabilities,” yet cited no specifics. The email author(s) wanted OpenJS to designate them as a new maintainer of the project despite having little prior involvement. This approach bears strong resemblance to the manner in which “Jia Tan” positioned themselves in the XZ/liblzma backdoor.
[…]
The OpenJS team also recognized a similar suspicious pattern in two other popular JavaScript projects not hosted by its Foundation, and immediately flagged the potential security concerns to respective OpenJS leaders, and the Cybersecurity and Infrastructure Security Agency (CISA) within the United States Department of Homeland Security (DHS).
The article includes a list of suspicious patterns, and another list of security best practices.
Last week, the Internet dodged a major nation-state attack that would have had catastrophic cybersecurity repercussions worldwide. It’s a catastrophe that didn’t happen, so it won’t get much attention—but it should. There’s an important moral to the story of the attack and its discovery: The security of the global Internet depends on countless obscure pieces of software written and maintained by even more obscure unpaid, distractible, and sometimes vulnerable volunteers. It’s an untenable situation, and one that is being exploited by malicious actors. Yet precious little is being done to remedy it.
Programmers dislike doing extra work. If they can find already-written code that does what they want, they’re going to use it rather than recreate the functionality. These code repositories, called libraries, are hosted on sites like GitHub. There are libraries for everything: displaying objects in 3D, spell-checking, performing complex mathematics, managing an e-commerce shopping cart, moving files around the Internet—everything. Libraries are essential to modern programming; they’re the building blocks of complex software. The modularity they provide makes software projects tractable. Everything you use contains dozens of these libraries: some commercial, some open source and freely available. They are essential to the functionality of the finished software. And to its security.
You’ve likely never heard of an open-source library called XZ Utils, but it’s on hundreds of millions of computers. It’s probably on yours. It’s certainly in whatever corporate or organizational network you use. It’s a freely available library that does data compression. It’s important, in the same way that hundreds of other similar obscure libraries are important.
Many open-source libraries, like XZ Utils, are maintained by volunteers. In the case of XZ Utils, it’s one person, named Lasse Collin. He has been in charge of XZ Utils since he wrote it in 2009. And, at least in 2022, he’s had some “longterm mental health issues.” (To be clear, he is not to blame in this story. This is a systems problem.)
Beginning in at least 2021, Collin was personally targeted. We don’t know by whom, but we have account names: Jia Tan, Jigar Kumar, Dennis Ens. They’re not real names. They pressured Collin to transfer control over XZ Utils. In early 2023, they succeeded. Tan spent the year slowly incorporating a backdoor into XZ Utils: disabling systems that might discover his actions, laying the groundwork, and finally adding the complete backdoor earlier this year. On March 25, Hans Jansen—another fake name—tried to push the various Unix systems to upgrade to the new version of XZ Utils.
And everyone was poised to do so. It’s a routine update. In the span of a few weeks, it would have been part of both Debian and Red Hat Linux, which run on the vast majority of servers on the Internet. But on March 29, another unpaid volunteer, Andres Freund—a real person who works for Microsoft but who was doing this in his spare time—noticed something weird about how much processing the new version of XZ Utils was doing. It’s the sort of thing that could be easily overlooked, and even more easily ignored. But for whatever reason, Freund tracked down the weirdness and discovered the backdoor.
It’s a masterful piece of work. It affects the SSH remote login protocol, basically by adding a hidden piece of functionality that requires a specific key to enable. Someone with that key can use the backdoored SSH to upload and execute an arbitrary piece of code on the target machine. SSH runs as root, so that code could have done anything. Let your imagination run wild.
This isn’t something a hacker just whips up. This backdoor is the result of a years-long engineering effort. The ways the code evades detection in source form, how it lies dormant and undetectable until activated, and its immense power and flexibility give credence to the widely held assumption that a major nation-state is behind this.
If it hadn’t been discovered, it probably would have eventually ended up on every computer and server on the Internet. Though it’s unclear whether the backdoor would have affected Windows and macOS, it would have worked on Linux. Remember in 2020, when Russia planted a backdoor into SolarWinds that affected 14,000 networks? That seemed like a lot, but this would have been orders of magnitude more damaging. And again, the catastrophe was averted only because a volunteer stumbled on it. And it was possible in the first place only because the first unpaid volunteer, someone who turned out to be a national security single point of failure, was personally targeted and exploited by a foreign actor.
This is no way to run critical national infrastructure. And yet, here we are. This was an attack on our software supply chain. This attack subverted software dependencies. The SolarWinds attack targeted the update process. Other attacks target system design, development, and deployment. Such attacks are becoming increasingly common and effective, and also are increasingly the weapon of choice of nation-states.
It’s impossible to count how many of these single points of failure are in our computer systems. And there’s no way to know how many of the unpaid and unappreciated maintainers of critical software libraries are vulnerable to pressure. (Again, don’t blame them. Blame the industry that is happy to exploit their unpaid labor.) Or how many more have accidentally created exploitable vulnerabilities. How many other coercion attempts are ongoing? A dozen? A hundred? It seems impossible that the XZ Utils operation was a unique instance.
Solutions are hard. Banning open source won’t work; it’s precisely because XZ Utils is open source that an engineer discovered the problem in time. Banning software libraries won’t work, either; modern software can’t function without them. For years, security engineers have been pushing something called a “software bill of materials”: an ingredients list of sorts so that when one of these packages is compromised, network owners at least know if they’re vulnerable. The industry hates this idea and has been fighting it for years, but perhaps the tide is turning.
The fundamental problem is that tech companies dislike spending extra money even more than programmers dislike doing extra work. If there’s free software out there, they are going to use it—and they’re not going to do much in-house security testing. Easier software development equals lower costs equals more profits. The market economy rewards this sort of insecurity.
We need some sustainable ways to fund open-source projects that become de facto critical infrastructure. Public shaming can help here. The Open Source Security Foundation (OSSF), founded in 2022 after another critical vulnerability in an open-source library—Log4j—was discovered, addresses this problem. The big tech companies pledged $30 million in funding after the critical Log4j supply chain vulnerability, but they never delivered. And they are still happy to make use of all this free labor and free resources, as a recent Microsoft anecdote indicates. The companies benefiting from these freely available libraries need to actually step up, and the government can force them to.
There’s a lot of tech that could be applied to this problem, if corporations were willing to spend the money. Liabilities will help. The Cybersecurity and Infrastructure Security Agency’s (CISA’s) “secure by design” initiative will help, and CISA is finally partnering with OSSF on this problem. Certainly the security of these libraries needs to be part of any broad government cybersecurity initiative.
We got extraordinarily lucky this time, but maybe we can learn from the catastrophe that didn’t happen. Like the power grid, communications network, and transportation systems, the software supply chain is critical infrastructure, part of national security, and vulnerable to foreign attack. The US government needs to recognize this as a national security problem and start treating it as such.
This essay originally appeared in Lawfare.
The cybersecurity world got really lucky last week. An intentionally placed backdoor in XZ Utils, an open-source compression utility, was pretty much accidentally discovered by a Microsoft engineer—weeks before it would have been incorporated into both Debian and Red Hat Linux. From ArsTehnica:
Malicious code added to XZ Utils versions 5.6.0 and 5.6.1 modified the way the software functions. The backdoor manipulated sshd, the executable file used to make remote SSH connections. Anyone in possession of a predetermined encryption key could stash any code of their choice in an SSH login certificate, upload it, and execute it on the backdoored device. No one has actually seen code uploaded, so it’s not known what code the attacker planned to run. In theory, the code could allow for just about anything, including stealing encryption keys or installing malware.
It was an incredibly complex backdoor. Installing it was a multi-year process that seems to have involved social engineering the lone unpaid engineer in charge of the utility. More from ArsTechnica:
In 2021, someone with the username JiaT75 made their first known commit to an open source project. In retrospect, the change to the libarchive project is suspicious, because it replaced the safe_fprint function with a variant that has long been recognized as less secure. No one noticed at the time.
The following year, JiaT75 submitted a patch over the XZ Utils mailing list, and, almost immediately, a never-before-seen participant named Jigar Kumar joined the discussion and argued that Lasse Collin, the longtime maintainer of XZ Utils, hadn’t been updating the software often or fast enough. Kumar, with the support of Dennis Ens and several other people who had never had a presence on the list, pressured Collin to bring on an additional developer to maintain the project.
There’s a lot more. The sophistication of both the exploit and the process to get it into the software project scream nation-state operation. It’s reminiscent of Solar Winds, although (1) it would have been much, much worse, and (2) we got really, really lucky.
I simply don’t believe this was the only attempt to slip a backdoor into a critical piece of Internet software, either closed source or open source. Given how lucky we were to detect this one, I believe this kind of operation has been successful in the past. We simply have to stop building our critical national infrastructure on top of random software libraries managed by lone unpaid distracted—or worse—individuals.
Cybercriminals are targeting Mac users interested in cryptocurrency opportunities with fake calendar invites. During the attacks the criminals will send a link supposedly to add a meeting to the target’s calendar. In reality the link runs a script to install Mac malware on the target’s machine.
Cybersecurity expert Brian Krebs investigated and flagged the issue.
Scammers, impersonating cryptocurrency investors, are active on Telegram channels to get interested people to attend a meeting about a future partnership.
One of those investors called Signum Capital tweeted a warning on X in January that one of their team members was being impersonated on Telegram and sending out invites by direct message (DM).
Heads up! A fake account pretending to be one of our team members is going around DM-ing people on Telegram.
— Signum Capital (@Signum_Capital) January 22, 2024
The screenshots below is from the scammer please take note and be alert. pic.twitter.com/6hFcUsaGtZ
The criminals reach out to targets by DM on Telegram and ask if they have an interest in hearing more about the opportunity in a call or meeting. If they show interest they will be sent a fabricated invitation for a meeting. When the times comes to join the meeting the invitation link doesn’t work. The scammers tell the victim it’s a known issue, caused by a regional access restriction, which can be solved by running a script.
We asked Malwarebytes Director of Core Technology and resident Apple expert Thomas Reed to look at this method. This isn’t the first time criminals have used scripts to compromise users, he told us.
“AppleScript has been used against Mac users with moderate frequency by malware creators over the years. It has the advantage of being very easy to write, and if compiled, is also extremely difficult to reverse engineer.”
According to Reed, AppleScripts can be provided in a few different forms. One is a simple .scpt file that opens in Apple’s Script Editor app. This has a few drawbacks for criminals: A victim would need to click something within Script Editor to run the script, and they would able to see the code, which might be a problem because AppleScript tends to be more human readable than most other scripts. However, there are ways to obfuscate what the code is doing, and many users won’t bother to read it anyway.
Another option is an AppleScript applet. This is something that acts like a normal Mac app. It contains a basic AppleScript executable and the script to be run. In this form, the script can be code signed, notarized, given an icon, and otherwise made to appear more trustworthy. The code could be pretty bland, and unlikely to trigger any kind of detection from Apple’s notarization process, but could download and execute something less trustworthy.
Scripts have another advantage for criminals, Reed warned.
“AppleScripts also have the advantage of being able to very easily get administrator permissions.”
A script that attempts to run a command with administrator privileges will ask users to authenticate, triggering a password dialog.
If the user enters their password, the script doesn’t actually get to see it, but everything else the script attempts to do “with administrator privileges” will successfully run as root without further authentication. This makes it very easy for the script to show a standard authentication request dialog and trick the user into giving root permissions.
“So, in summary, AppleScript can be quite effective for writing malware. In fact, some malware has been written exclusively – or almost exclusively – in AppleScript, such as OSX.DubRobber or OSX.OSAMiner.”
In this case, the script was a simple Apple Script that downloaded and executed a macOS-oriented Trojan. The nature of the Trojan is unknown, but it certainly won’t surprise anyone if it turns out it was a banking Trojan that specializes in stealing cryptocurrencies.
To avoid falling victim to these scammers, it’s good to know a few of their tactics.
Login.scpt (Apple script) extension.The presence of Mac malware is unfortunately still underestimated, but you can find protection by Malwarebytes for Mac and protect Mac endpoints in your environment by ThreatDown solutions.
We don’t just report on threats—we remove them
Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.
First-person account of someone who fell for a scam, that started as a fake Amazon service rep and ended with a fake CIA agent, and lost $50,000 cash. And this is not a naive or stupid person.
The details are fascinating. And if you think it couldn’t happen to you, think again. Given the right set of circumstances, it can.
It happened to Cory Doctorow.
EDITED TO ADD (2/23): More scams, these involving timeshares.
