24 Hour Technical Support & Seattle Computer Repair
support@seattlecomputer.repair (206) 657-6685
We accept insurance coverage!
Virus, Spyware, & Malware Removal
- Details
- Tech Support by: Emerald City IT
- Support Field: Computer Repair and Tech Support
- Support Category: Virus, Spyware, & Malware Removal
Executive Summary & Key Takeaways
As security professionals, we often live and die by the release cycle of the latest vulnerabilities. In this report, sponsored by F5 Labs, we take a step back and examine the universe of vulnerabilities (defined by the CVE) and how it’s changed in the last 20 years. As you will see, we find some surprising things along the way.
- The CVE landscape has changed substantially in the last two decades, with an increasing number and widening variety of vulnerabilities
- Some of those changes are due to the evolution of technology while some are “genetically modified”, i.e., how data is collected has changed rather than the data itself
- The number of CVEs published is accelerating, and we expect 500 new CVEs to be published in a typical week in 2025.
- New vulnerability territory is being uncovered every day
- Growing number of vendors: vendors publishing their first CVE are increasing at a rate of 18% per year
- Growing diversity of flaws: the number of unique software flaws (CWEs) present in any month’s worth of new CVEs has increased from about 20 to more than 130
- Both new and old territory is being reformed
- The OWASP top 10 has shifted dramatically over time
- The diversity of weakness in software has increased
- The language used in CVE descriptions is changing with less of a focus on Actors and Outcomes, and more focus on Weakness and Requirements
- The severity of CVEs (as measured by the CVSSv3 score) is not increasing
- CVSSv3 has a higher average severity than v2
- BUT the average severity of each hasn’t increased in the last decade
- CNAs and NVD often disagree on the severity of vulnerabilities
- Exploit code and exploitation in the wild has changed
- Older vulnerabilities were likely (sometimes as high as 1/3rd!) to have exploit code in ExploitDB
- Newer vulnerabilities are more likely to have exploit code appear in GitHub, though at a much lower rate (~5%)
- The size of the CISA Known Exploited Vulnerability List continues to grow, both in total size and the percentage of all CVEs
Introduction
We’ve all been there. After a hard day defending networks against foes—real and imaginary alike—we try to take a break from the big screen and scroll a bit through social media on the little screen1. Then, we see it: that infosec influencer account with the weird eye avatar is posting about a new vulnerability. This one is gonna be big apparently; it affects widely used software and may even be remote executable. There might be proof of concept code available, or maybe it’s already being exploited. Details remain murky for the next few hours of refreshing all of our possible feeds until the CVE drops. Evaluate, cancel weekend plans, soothe C-Suite worries, put out the fire, and start again.
The pendulum swings between the monotony of defending our networks from threats aimed at the backlog of known vulnerabilities and the panic of addressing the next big name brand vulnerability. The monotony and the panic both tend to leave us with a myopic view of individual vulnerabilities, while the overall vulnerability landscape is just a background blur. In this report, sponsored by F5 Labs and completed by the Cyentia Institute, we want to take a step back and try to bring that landscape into focus, and ask a few questions about where we’ve been and where we are going.
In particular, we are going to focus on individual vulnerabilities as they are often at the nexus of our security thinking. Moreover, because of the heroic efforts of those in our community, vulnerabilities are relatively well cataloged via the Common Vulnerabilities and Exposures (CVE) process2 with numerous sources of data about them publicly available. We’ll use this open data to take a retrospective as well as prescient view of the landscape, providing deep, quantified answers to sticky questions such as:
- How fast is the number of vulnerabilities growing?
- What are the most common types of vulnerabilities?
- Are vulnerabilities more severe now than they were before?
- How many vulnerabilities actually have exploit code published?
- How has the language we use to talk about vulnerabilities changed?
We’ll give some answers to the above questions, but along the way, we’ll have to step lightly. The world is a complex place and the way data is collected has changed over time and depending on who exactly is doing the collecting. So we’ll point out the results we think are real bona fide trends, as well as those that are just artifacts of the data collection process. To that end, we’ll try to make some observations about absolutely weird things in the vulnerability landscape.
The Basics
Before we dive in and try to start to survey the wide, weird world of vulnerabilities, it’s worthwhile to pause for a moment to define exactly what we mean by “vulnerability”. For our purposes, a “vulnerability” means a flaw that has a CVE ID assigned to it. We acknowledge that this is not the full universe of vulnerabilities, but it’s the easiest set to analyze and the one most often used3. Given that we are focusing on the CVE, let’s start with some definitions and examine the history of the CVE as well as a brief overview of some of the data fields from which CVEs are constructed.
Glossary
- Common Vulnerability and Exposures (CVE) A framework developed at the MITRE corporation for organizing information around computer vulnerabilities.
- Common Weakness Enumeration (CWE) A framework developed at the MITRE corporation for hierarchically organizing the types of software flaws that lead to vulnerabilities. CWE information is included in a CVE.
- OWASP Top 10 A subset of CWEs, published by the Open Web Application Security Project (OWASP), and deemed by it to be the most critical security vulnerabilities.
- Common Platform Enumeration (CPE) A framework developed, again, at MITRE corporation, that enumerates all possible software versions that are affected by a vulnerability, including the type, vendor, product, and version of software affected.
- CVE Number Authority (CNA) An entity that is bestowed with the power to publish new CVEs.
- Common Vulnerability Scoring System (CVSS) A method for assessing a vulnerability's severity.
- Known Exploited Vulnerabilities (KEV) A list of CVEs published by the United States Department of Homeland Security indicating vulnerabilities that are actually being used in the wild.
A Brief History of the CVE
We are not historians here at Cyentia, and so we don’t claim this to be a definitive history of the CVE4. But we do want to highlight some of the important waypoints visited to get to where we are today. One major theme is that the socio-technical process of creating a framework that fits everyone’s use case is a complex one, and it often takes a long time before the stakeholders arrive at something everyone can agree with, or at least not disagree with.
The idea for a framework for gathering information about vulnerabilities was first presented at the 2nd Workshop on Research with Security Vulnerability Databases in January of 1999 by Dave Mann and Steve Christey. Because the question of how to share information about vulnerabilities requires broad community buy-in, a working group was formed to create a more formal framework. Approximately nine months later5, the first CVE list was birthed into the world in September of 1999 with a mere 321 vulnerabilities. My, how things have grown (over 190k have been published since then!); we are now at nearly 200k.
In the early days, there was a lot of necessary wrangling to get buy-in from various different parts of the community (MITRE, vendors, industry practitioners, and governments). The result of this wrangling was that while the MITRE CVE list grew, another database using the CVE framework with a slightly different mission came into existence: the Internet Category of Attacks Toolkit (ICAT)6. ICAT was a NIST project headed by Peter Mell7. Early versions of the ICAT were cheeky, leaning into the “CAT” in ICAT (Figure 1).
- Details
- Tech Support by: Emerald City IT
- Support Field: Computer Repair and Tech Support
- Support Category: Virus, Spyware, & Malware Removal
ALBUQUERQUE, N.M. — A cybersecurity technique that shuffles network addresses like a blackjack dealer shuffles playing cards could effectively befuddle hackers gambling for control of a military jet, commercial airliner or spacecraft, according to new research. However, the research also shows these defenses must be designed to counter increasingly sophisticated algorithms used to break them.
Sandia National Laboratories cybersecurity expert Chris Jenkins sits in front of a whiteboard with the original sketch of the moving target defense idea for which he is the team lead. When the COVID-19 pandemic hit, Jenkins began working from home, and his office whiteboard remained virtually undisturbed for more than two years. (Photo by Craig Fritz) Click on the thumbnail for a high-resolution image.
Many aircraft, spacecraft and weapons systems have an onboard computer network known as military standard 1553, commonly referred to as MIL-STD-1553, or even just 1553. The network is a tried-and-true protocol for letting systems like radar, flight controls and the heads-up display talk to each other.
Securing these networks against a cyberattack is a national security imperative, said Chris Jenkins, a Sandia National Laboratories cybersecurity scientist. If a hacker were to take over 1553 midflight, he said, the pilot could lose control of critical aircraft systems, and the impact could be devastating.
Jenkins is not alone in his concerns. Many researchers across the country are designing defenses for systems that utilize the MIL-STD-1553 protocol for command and control. Recently, Jenkins and his team at Sandia partnered with researchers at Purdue University in West Lafayette, Indiana, to test an idea that could secure these critical networks.
Their results, recently published in the scientific journal IEEE Transactions on Dependable and Secure Computing, show that done the right way, a technique already known in cybersecurity circles, called moving target defense, can effectively protect MIL-STD-1553 networks against a machine-learning algorithm. Sandia’s Laboratory Directed Research and Development program funded the research.
“When we talk about protecting our computer systems, frequently there are two main pieces we rely on,” said Eric Vugrin, a Sandia cybersecurity senior scientist who also worked on the project. “The first approach is just keeping the bad guy out and never permitting access to the system. The physical analogue is to build a big wall and don’t let him in in the first place. And the backup plan is, if the wall doesn’t work, we rely on detection. Both of those approaches are imperfect. And so, what moving target defense offers as a complementary strategy is, even if those two approaches fail, moving target confuses the attacker and makes it more difficult to do damage.”
Moving target defense must keep cyberattackers guessing
Like a game of three-card monte, in which a con artist uses sleight of hand to shuffle cards side-to-side, moving target defense requires randomness. Without it, the defense unravels. Researchers wanted to know whether a moving target defense would work to constantly change network addresses, unique numbers assigned to each device on a network. They weren’t sure it would work because, compared to other types of networks, MIL-STD-1553’s address space is small and therefore difficult to randomize.
Aboard the 58th Special Operations Wing’s C-130 transport aircraft at Kirtland Air Force Base, Christy Sturgill, Jacob Hazelbaker, Eric Vugrin and Nicholas Troutman, from left to right, were part of the Sandia National Laboratories team working on a moving target defense that makes a computer network commonly used on space and aircraft less vulnerable to cyberattack. (Photo by Craig Fritz) Click on the thumbnail for a high-resolution image.
For example, the strategy has proven useful with internet protocols, which have millions or billions of network addresses at their disposal, but 1553 only has 31. In other words, Sandia had to come up with a way to surreptitiously shuffle 31 numbers in a way that couldn’t easily be decoded.
“Someone looked me in the face and said it’s not possible because it was just 31 addresses,” Jenkins said. “And because the number is so small compared to millions or billions or trillions, people just felt like it wasn’t enough randomness.”
The challenge with randomizing a small set of numbers is that “Nothing in computer software is truly random. It’s always pseudorandom,” said Sandia computer scientist Indu Manickam. Everything must be programmed, she said, so there’s always a hidden pattern that can be discovered.
With enough time and data, she said, “A human with an Excel sheet should be able to get it.”
Manickam is an expert in machine learning, or computer algorithms that identify and predict patterns. These algorithms, though beneficial to cybersecurity and many other fields of research and engineering, pose a threat to moving target defenses because they can potentially spot the pattern to a randomization routine much faster than a human.
“We’re using machine-learning techniques to better defend our systems,” Vugrin said. “We also know the bad guys are using machine learning to attack the systems. And so, one of the things that Chris identified early on was that we do not want to set up a moving target defense where somebody might use a machine-learning attack to break it and render the defense worthless.”
Sophisticated algorithms don’t necessarily spell the end for this type of cyberdefense. Cybersecurity designers can simply write a program that changes the randomization pattern before a machine can catch on.
But the Sandia team needed to know how fast machine learning could break their defense. So, they partnered with Bharat Bhargava, a professor of computer science at Purdue University, to test it. Bhargava and his team had been involved previously in researching aspects of moving target defenses.
For the last seven years, Bhargava said, the research fields of cybersecurity and machine learning have been colliding. And that’s been reshaping concepts in cybersecurity.
“What we want to do is learn how to defend against an attacker who is also learning,” Bhargava said.
Test results inform future improvements to cybersecurity
Jenkins and the Sandia team set up two devices to communicate back and forth on a 1553 network. Occasionally, one device would slip in a coded message that would change both devices’ network addresses. Jenkins sent Bhargava’s research team logs of these communications using different randomization routines. Using this data, the Purdue team trained a type of machine-learning algorithm called long short-term memory to predict the next set of addresses.
The first randomization routine was not very effective.
“We were not only able to just detect the next set of addresses that is going to appear, but the next three addresses,” said Ganapathy Mani, a former member of the Purdue team who contributed to the research.
The algorithm had scored 0.9 out of a perfect 1.0 on what’s called a Matthews correlation coefficient, which rates how well a machine-learning algorithm performs.
But the second set of logs, which used a more dynamic routine, resulted in a radically different story. The algorithm only scored 0.2.
“0.2 is pretty close to random, so it didn’t really learn anything,” Manickam said.
The test showed that moving target defense can fundamentally work, but more importantly it gave both teams insights into how cybersecurity engineers should design these defenses to withstand a machine-learning-based assault, a concept the researchers call threat-informed codesign.
Defenders, for example, could “Add fake data into it so that the attackers cannot learn from it,” Mani said.
The findings could help improve the security of other small, cyber-physical networks beyond MIL-STD-1553, such as those used in critical infrastructure.
Jenkins said, “Being able to do this work for me, personally, was somewhat satisfying because it showed that given the right type of technology and innovation, you can take a constrained problem and still apply moving target defense to it.”
Sandia National Laboratories is a multimission laboratory operated by National Technology and Engineering Solutions of Sandia LLC, a wholly owned subsidiary of Honeywell International Inc., for the U.S. Department of Energy’s National Nuclear Security Administration. Sandia Labs has major research and development responsibilities in nuclear deterrence, global security, defense, energy technologies and economic competitiveness, with main facilities in Albuquerque, New Mexico, and Livermore, California.
Sandia news media contact: Troy Rummler,
- Details
- Tech Support by: Emerald City IT
- Support Field: Computer Repair and Tech Support
- Support Category: Virus, Spyware, & Malware Removal
- Details
- Tech Support by: Emerald City IT
- Support Field: Computer Repair and Tech Support
- Support Category: Virus, Spyware, & Malware Removal
To exploit this vulnerability, the image must be created under very specific condition listed here.
According to the information provided by Microsoft, "The default Snipping Tool in Windows 10 and older versions are unaffected. Only Snip & Sketch in Windows 10 and Snipping Tool in Windows 11 are affected by this vulnerability. A security update has been released for these applications, which are available through the Microsoft Store."[1]
This is the information provide to verify if the system is affected:
For Snip and Sketch installed on Windows 10, app versions 10.2008.3001.0 and later contain this update.
For Snipping Tool installed on Windows 11, app versions 11.2302.20.0 and later contain this update.
[1] https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-28303
[2] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-28303
[3] https://apps.microsoft.com/store/detail/snipping-tool/9MZ95KL8MR0L?hl=en-us&gl=us
-----------
Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu
- Details
- Tech Support by: Emerald City IT
- Support Field: Computer Repair and Tech Support
- Support Category: Virus, Spyware, & Malware Removal
Introduction
Threat actors are taking advantage of Microsoft OneNote's ability to embed files and use social engineering techniques, such as phishing emails and lures inside the OneNote document, to get unsuspecting users to download and open malicious files. Once clicked, an attacker can use the embedded code for various malicious purposes, such as stealing data or installing ransomware on victims' systems.
Last December, we discovered a malicious campaign involving a trojanized OneNote document delivering Formbook. The campaign is an example of a shift away from macro-enabled documents after Microsoft tightened security measures for files downloaded from the Internet, making macro-based attacks less effective.
We recently observed a notable spike in emails utilizing malicious OneNote attachments with notorious malware strains also shifting to this delivery mechanism. This multi-part blog series highlights recent campaigns we observed using this technique.
What is OneNote?
OneNote is a note-taking application developed by Microsoft and bundled in its Office application suite. It allows users to take notes, organize information and insert files such as images, documents, and even executables. It is a popular application used by many organizations and individuals.
OneNote files use .ONE as a filename extension. A OneNote document consists of sections, pages, and user-created content. Unlike DOCX and XLSX, OneNote does not support VBA macros.
Infostealer
The first campaign uses a fake product inquiry to lure users into downloading a OneNote attachment. Trustwave’s MailMarshal manages to unpack and extract the contents of that OneNote document making it easy to spot suspicious embedded files.
Figure 1. A fake product inquiry email with attached malicious OneNote document. MailMarshal manages to extract the images, texts and executable embedded in the OneNote notebook making it easy to spot suspicious contents.
The OneNote document purports to be a product inquiry document in PDF format. Once the user clicks the ‘View Document’ button, it loads an embedded executable sporting the right-to-left override (RTLO or RLO) trick making it appear as ‘Orderinvpif.pdf’ to the user and flipping the extension ‘pdf.pif’. In addition, the executable masquerades as an Adobe PDF Reader icon. Like the sample we saw last December, the embedded file abuses the RTLO character (U+202E) to disguise the file name making it appear harmless.
An embedded fake inquiry PDF pops out once the executable is clicked. The fake inquiry tricks the user into thinking that the opened file is a legitimate document, but in the background malicious activities were conducted.
Figure 2. Trojanized OneNote document with one section using PDF viewer as a lure to let targets click on the ‘View Document’ button.
Infection chain
Figure 3. High-level view of the infection routine of the campaign with email as initial access vector.
The threat actor created the with PyInstaller, a library that packages Python programs into standalone executables. Using pyinstxtractor, we extracted the contents of the PyInstaller package - the version of Python used to generate the executable - and the possible entry points of the executable. The sample was packed and created with Python 3.10. We investigated each entry point, and what caught our eye was the script ‘contain.pyc,’ which holds the Python bytecode of the primary payload.
Figure 4. Extraction logs of pyinstxtractor for our PyInstaller-based executable, it identified possible entry points and revealed that the executable was packed with PyInstaller 2.1 with Python version 3.10.
Embedded PowerShell Script
While inspecting the bytecode, we noticed it contains a chain of PowerShell commands. The command starts by comparing the current date with the preset start and end date and ensures it runs within the preset time period. It also checks if it is running in virtual environments, like VirtualBox, VMWare, or Hyper-V. Both techniques are used to detect and evade analysis environments.
Using the Get-WinHomeLocation command, the PowerShell code retrieves the current user’s home location or country, followed by the whoami command to get the current username. The user’s home location and username will then create subfolders in the %APPDATA%/Creds/ directory storing the stolen information.
The code then collects system information using the PowerShell command Get-ComputerInfo and stores the information in a text file. Below is additional information collected from the victim:
- Public IP address through the service http://ifconfig[.]me/ip
- Network adapters using the command ipconfig/all
- Browsing history by traversing the %APPDATA% directory of browsers
- Stored WiFi passwords with the command netsh wlan show profile name="<profile>" key=clear
Figure 5. The PowerShell script initially sets up defense evasion like AV scanning path exclusion and VM checks followed by credential harvesting.
To further collect browser data, the script downloads a ZIP package from https[://]evilextractor.com/wp-content/uploads/2022/12/Python39-322.zip containing a portable Python package and toolsets.
Figure 6. The script downloads a ZIP archive containing a set of tools to assist in harvesting further data.
Included in the package are the utilities ChromeCookiesView and MZCookiesView. These are freeware created by NirSoft that extract cookies, history data, and cache information from web browsers. ChromeCookiesView and MZCookiesView are used by threat actors for malicious purposes.
Figure 7. The contents of the ZIP archive include ChromeCookiesView.exe, MozillaCookiesView (mzcv_32.exe, mzcv_64.exe), a python script - soax.py for password harvesting, and all others are part of the Python 3.9 package.
A Python script named soax.py, obfuscated with PyArmor, is part of the toolset used to collect web browser and mail client passwords.
Figure 8. PowerShell Code snippet running the Python script - soax.py, executed against browsers and mail clients to harvest passwords.
Moreover, the PowerShell script searches for images, videos, documents, archives, and text files from victims’ desktops and download folders then copies each file in the %APPDATA%/Creds/ folder.
The stolen data, which ranges from from browser credentials to user files, are stored in %APPDATA%/Creds/ were exfiltrated to a remote FTP server operated by the threat actor. The FTP credentials were embedded in the script.
Figure 9. These are the file extensions of interest being harvested from desktop and download folders of the victims’ machines. All the data stolen is exfiltrated through a remote FTP server controlled by the threat actor. The FTP credentials are hardcoded in the script.
The script downloads another tool called CommandCam directly from the developer’s GitHub repository. The tool captures webcam images from the command line. The images were then stored in the %APPDATA%/Ss/ directory and exfiltrated through FTP on the same server used by the threat actor.
Figure 10. To capture webcam images, it downloads a tool called CommandCam. It also takes a screenshot of the target machine using PowerShell commands.
To cap everything off, the script cleans up all PowerShell logs, downloaded files and captured webcam images to conceal its traces.
Conclusion
Trojanized OneNote documents have grown in popularity among threat actors since we first spotted them in the wild. It is highly likely that threat actors are achieving their objectives using this delivery method in conjunction with tricky social engineering.
This threat is a relevant example of threat actors chaining legitimate open-source and free tools to carry out malicious attacks. These tools tend to be overlooked and could potentially evade security measures. The overall infection chain is simple yet powerful, posing a severe threat to end-users.
In the second part of this series, we’ll go over an infection chain that leads to AsyncRAT malware. We will also provide an overview of other notable malware strains.
Indicators of Compromise
ftp[://]191[.]96[.]63[.]60 | FTP Server |
5a513d230db2bd983575be5902ee2db07dad96c1 | Orderinvpdf.pif |
2046c77280cb39966b1bbbcab6bdf3d35f5bd72a | P0220230123.one |