Cyber Security Experts


Leaky Backup Spills 157 GB of Automaker Secrets

An insecure backup protocol used by robotics firm Level One is to blame for leaking 157 gigabytes of sensitive data belonging major automakers, including Ford, Tesla and Toyota.

The data included 10 years of assembly-line schematics and control settings for robotics used to build the cars, along with internal ID and VPN-request forms.

To blame was rsync, which stands for “remote sync,” a common file transfer protocol used to mirror or backup large data sets, according to UpGuard Cyber Risk team that first reported the problem on Friday.

An attacker that compromised the service could use the data to “sabotage or otherwise undermine operations using the information present in these files; competitors could use them to gain an unfair advantage,” UpGuard researchers said, adding, “The sheer amount of sensitive data and the number of affected businesses illustrate how third- and fourth-party supply-chain cyber-risk can affect even the largest companies.”

A report released Monday on supply-chain attack readiness revealed 87 percent of businesses that had active measures to thwart software supply-chain attacks fell victim to one, despite defenses.

A total of seven auto companies were impacted by the data leak, including divisions of automakers Chrysler, Ford, GM, Tesla, Toyota and Volkswagen, along with automotive supplier ThyssenKrupp. Level One also inadvertently leaked its own internal data, including employee scans of driver’s licenses and passports, along with invoices, contracts, and bank-routing numbers and SWIFT codes.

Leaky backup services differ from insecure, misconfigured AWS and Mongo databases, which have gained a high profile as being often left accessible to anyone on the internet. Leaky rsync services are typically a result of permissions set on the rsync server. In the case of Level One, the rsync server was publicly writable.

“The rsync server was not restricted by IP or user, and the dataset was downloadable to any rsync client that connected to the rsync port,” UpGuard wrote. The analysts added, “[That means] someone could potentially have altered the documents there, for example replacing bank account numbers in direct deposit instructions, or embedding malware.”

rsync has been the culprit behind many high-profile supply-chain related leaks in the past years. In 2017, sensitive data was leaked by a Pentagon contractor. In the same timeframe, contractor Power Quality Engineering publicly exposed sensitive electrical infrastructure data belonging to the City of Austin, Dell Technologies, Freescale, Oracle, SBC and Texas Instruments.

top feature image

Spectre Will Haunt Us For a Long Time

During a recent Congressional hearing, Senators voiced concerns about the ongoing Spectre and Meltdown vulnerabilities. While the technical details were predictably glossed over, most of the hearing focused on Intel informing Chinese partners about the flaws six months before they went public. While this is troubling and potentially gave foreign hackers a longer window of opportunity, it misses the much bigger issue: These vulnerabilities have existed for over 20 years, and we are not even close to closing the door on these significant risks.

Willy Leichter

Willy Leichter

The research paper that revealed Spectre in January stated it succinctly: “As it is not easy to fix, it will haunt us for quite some time.”

How We Got Here

Spectre and Meltdown are speculative side-channel flaws that make use of a basic fact of how modern computing works. Starting with the first Intel Pentium processors in 1995, chip designers found clever ways boost processor speed by leveraging unused processor cycles and guessing what’s coming next. This caching model (allowing the chipset to make assumptions about next steps, known as branch prediction and speculative execution, to get a jump on computing) has been embedded in the millions of processors since then, and we’ve all come to expect the performance benefits that come from it.

What was not considered is that these speculative cycles jump ahead of security checks – and hackers have now found side-channels and sophisticated timing mechanisms that can be used to exploit these short windows of exposure.

Thus, Spectre and Meltdown burst on the scene in early 2018. While Meltdown breaks down the mechanism keeping applications from accessing arbitrary system memory, Spectre tricks other applications into accessing arbitrary locations in their memory.

The upshot is that the flaws allow attackers to steal passwords, customer data, IP and more stored in the memory of programs running on a victim’s machine.

The unprecedented scope of the vulnerabilities is what made headlines: They create exposures across PCs, Macs, mobile devices and even virtual machines in the cloud.

A Problem Without a (True) Patch

Initial fixes were rushed out, with many unintended consequences. Software vendors offered operating system (OS) patches, but these caused unacceptable performance loss and were quickly withdrawn. Processor microcode updates were released, but ended up often disabling servers – so most customers steered clear of these risky updates. Chipmakers meanwhile promised future chips without these flaws would be “available soon” – which of course does nothing to address the millions and millions of vulnerable devices already in the field.

With each round of patching, users have been asked to make unacceptable choices – they must either compromise performance (by as much as 30 percent); re-compile source code completely, which takes expertise and labor; or replace the processors – a daunting task for enterprises especially, which may have thousands of computers to fix.

Meanwhile, many have rationalized that the problem is only theoretical – i.e., created by researchers in the lab and too difficult for hackers to implement in the wild. But this wishful thinking has been shaken as multiple new variants of Spectre continue to emerge, causing the same patching scramble and leading to incomplete remedies.

A Failure of Imagination

Assuming that these risks are only theoretical is both naïve and dangerous.

Throughout the last century, many disasters including 9/11, the Apollo 1 fire, Pearl Harbor and the sinking of the Titanic were blamed on a “failure of imagination.” The phrase is a handy label for something that was deemed inconceivable at the time, but emerged as an obvious danger after the fact. The chip-design flaws leading to Spectre and Meltdown fall into this category.

We also don’t have to look back far for other examples of failures of imagination in cybersecurity: In 2010, Stuxnet caused waves as NSA-developed tools brought down Iranian centrifuges with unprecedented fileless and memory-based techniques. These advanced exploits were considered arcane and only practical for nation-states — until it emerged in other scenarios. It also paved the way for the recent explosion of memory-based attacks, including WannaCry, NotPetya, Industroyer, Equifax, Triton and many others.

Fueled by the ShadowBrokers leaks, highly dangerous hacking tools are now readily available to mainstream hackers, and these previously theoretical attacks are now common. It’s hard to believe that Spectre won’t follow a similar trajectory.

Adding to the problem is the fact that the computing space is rife with traditional silos. Software developers don’t worry about the many layers in the stack below their code, and very few people (outside the chip industry) understand the microcode and hardware supporting all of our computing – from cell phones to cloud.

It’s imperative that we rethink our approach, challenge assumptions, break through silos and take strong measures to change underlying structural weaknesses.

top feature image

New Spectre-Level Flaw Targets Return Stack Buffer

Researchers have discovered yet another speculative execution side-channel flaw enabling attackers to access sensitive data at the CPU level.

The new Spectre-class exploit, dubbed SpectreRSB, was detailed by researchers from the University of California at Riverside in a research paper on Friday. While the flaw still targets the process of speculative execution, unlike other variants, it manipulates a new part of the process called the return stack buffer.

“In this paper, we introduce a new attack vector for Spectre-like attacks that are not prevented by deployed defenses,” researcher Nael Abu-Ghazaleh wrote in the paper. “Specifically, the attacks exploit the return stack buffer (RSB) to cause speculative execution of the payload gadget that reads and exposes sensitive information.”

RSB is a common “predictor structure” in CPUs used to predict return addresses during the speculative execution process. It does so by pushing the return address from a call instruction on an internal hardware stack; thus supporting speculation with very high accuracy.

Speculative execution is used in microprocessors so that memory can read before the addresses of all prior memory writes are known. This enables an attacker with local user access using a side-channel analysis to gain unauthorized disclosure of information. Since the disclosure of Spectre in January, various variants have consequently been disclosed by researchers – however, these have all targeted the branch predictor unit or cache within the CPU.

“The RSB can be thought of as another branch predictor used for the return instructions (whereas the primary branch predictor is used for branch instructions)…  So, this attack is similar to Spectre, but with a different entry point that has some different properties,” Abu-Ghazaleh told Threatpost via email.

RSB can be manipulated through user code and “direct pollution of the RSB,” where a bad actor could insert a call instruction as a value pushed to the RSB and the software stack. The stack is subsequently manipulated by the user so that the return address no longer matches the RSB – allowing the attacker to recover data running on the CPU.

“To launch the attack, the attacker should poison the RSB (a different and arguably easier process than poisoning the branch predictor) and then cause a return instruction without a preceding call instruction in the victim (which is arguably more difficult than finding an indirect branch),” Abu-Ghazaleh told us. He said SpectreRSB should be thought of as a variant of Spectre, with about the same order of difficulty and capabilities as the original attack.

SpectreRSB also enables an attack against the SGX compartment, where a malicious OS pollutes the RSB to cause a misspeculation that exposes data outside an SGX compartment. This attack bypasses all software and microcode patches on the SGX machine.

Researchers said they have reported SpectreRSB to Intel, AMD and ARM – all of which use RSBs to predict return addresses. AMD and ARM did not respond to a request for comment from Threatpost.

RSB Stuffing and Patches

Researchers alleged that the new flaw is not prevented by any of the previous known defenses against Spectre, including Google’s software fix, Retpoline, and Intel’s microcode patches.

However, in a statement to Threatpost, Intel argued that this is not the case: “SpectreRSB is related to branch target injection (CVE-2017-5715), and we expect that the exploits described in this paper are mitigated in the same manner,” an Intel spokesperson said via email.  “We have already published guidance for developers in the whitepaper, Speculative Execution Side Channel Mitigations. We are thankful for the ongoing work of the research community as we collectively work to help protect customers.”

Regardless of other patches, the UC-Riverside researchers said that a defense does exist to mitigate against SpectreRSB, dubbed “RSB stuffing.” This currently exists on Intel’s Core i7 processors (starting from its Skylake lineup).

With RSB stuffing (a.k.a. RSB refilling), every time there is a switch into the kernel, the RSB is intentionally filled with the address of a benign delay gadget to avoid the possibility of misspeculation.

“For some of the more dangerous attacks, the attack starts from the user code, but its trying to get the OS to do the return to the poisoned address,” Abu-Ghazaleh told Threatpost. “Refilling overwrites the entries in the RSB whenever we switch to the kernel (for example, at the same points where the KPTI patch remaps the kernel addresses).  So, the user cannot get the kernel to return to its poisoned addresses in the RSB.”

top feature image

Join Forces on Data Portability

A veritable who’s who of tech giants from Google, Facebook, Microsoft and Twitter, went public last week with a partnership on a standards initiative called the Data Transfer Project (DTP), built to enable data portability between cloud platforms. But security researchers believe the project’s privacy implications need to be better vetted.

Towards a Universal Data Portability Framework

This framework will include tools that can convert any service’s proprietary APIs to and from a small set of standardized data formats to ones that can be used by anyone. Using as a starting point publicly available APIs from Google, Microsoft, Twitter, Flickr, Instagram, Remember the Milk and SmugMug, the framework would allow seamless data transfer (only with user consent) for a range of information, including photos, mail, contacts, calendars and tasks. The idea is to create one, open-source approach that will enable consumers to “transfer their data directly from one service to another, without needing to download and re-upload it,” according to a Google blog post on Friday.

“This makes it possible to transfer data between any two providers using existing industry-standard infrastructure and authorization mechanisms, such as OAuth,” Google explained.

The benefits are varied; for one, the interoperability will make it easier for users to move their cherished digital data from one service to another without worrying that something will be lost in translation, and without having to jump through a lot of hoops. That should make trying out or moving to a new service easier. It also can pave the way for better data backups. Microsoft, in a blog post on Friday, struck a more general note, saying that “portability and interoperability are central to cloud innovation and competition.”

Pravin Kothari, CEO of cloud security vendor CipherCloud, listed out for Threatpost some positives for consumers: “The DTP may enable users to back up important information, organize their data across different accounts, recover more rapidly from cyber-events like account hijacking, and retrieve data from old or to be discontinued services.”

Chris Olson, CEO of The Media Trust, also pointed out that there’s a data-control upside. “The Data Transfer Project could be a game changer – you have the biggest tech companies facilitating consent-based sharing of consumer data, and you have consumers more able to manage the data that companies collect on them,” he told Threatpost in an email.

Google echoed this in the posting: “As it is an open-source product, anyone can inspect the code to verify that data isn’t being collected or used for profiling purposes.”

Google in its posting also laid out the security aspects of the DTP.

“Services must first agree to allow data transfer between them, and then they will require that individuals authenticate each account independently,” it explained. “All credentials and user data will be encrypted both in transit and at rest. The protocol uses a form of perfect forward secrecy where a new unique key is generated for each transfer. Additionally, the framework allows partners to support any authorization mechanism they choose. This enables partners to leverage their existing security infrastructure when authorizing accounts.”

Concerns Remain

There are some potential privacy pitfalls to the DTP idea, James Lerud, head of the behavioral research team at Verodin, told Threatpost.

“The project does not make it easy to remove service A’s existing access to data,” he explained via email. “Taken by itself, the project does little to improve the security of consumer data; it provides new options for consumers to safely share data between services. The distinction is that consumers may gain control over transferring data, while the security of the data is unchanged or potentially diminished by having copies of data stored in multiple services.”

Brian Vecci, technical evangelist at Varonis, had similar thoughts.

“On its face, this sounds like a great way to give users more control over their own data, making it easier to get your information from one source to another,” he told Threatpost via email. “There are significant privacy concerns with this, though. Transferring data like this almost certainly doesn’t mean that data will be deleted on the source service, so while you get the convenience of having information in multiple places, there are also now multiple places where your data can be lost, stolen or misused in some way.”

The concern is especially piquant given that regulations like the recently enacted GDPR in the European Union lays out strict privacy for protections for user data.

“GDPR is forcing companies to be very careful with what data they collect, who potentially has access to it, how it’s used and when it’s supposed to be deleted,” said Vecci. “This is generally easier for data that’s collected organically as part of a specific process, like when you enter your contact information into a website.”

On the other hand, “when you grant a company an entire dump of past data from another source, the potential for that information to end up in places where it’s not properly tracked or kept private is potentially higher,” he said. “Consumers should be careful about what kind of data they provide to which companies.”

top feature image

Oracle Re-Patches Decade-Old Solaris Bug

Oracle has issued three fixes for a critical Solaris vulnerability that could allow kernel-level privilege escalation. Impacted are the Solaris 10 and 11.3 operating environments.

Sun Microsystems (now owned by Oracle) originally patched the vulnerability in 2009. But, a “re-fix” is now required, since researchers at Trustwave discovered loopholes in the patch that could allow a local adversary to execute arbitrary code on Solaris enterprise systems and escalate privileges.

“The issue is present in the kernel and is locally exploitable as an unprivileged user, provided the local system has the Sun StorageTek Availability Suite configured,” explained Neil Kettle, application security principal consultant at SpiderLabs at Trustwave.

The vulnerability allows attackers to write their own malicious code to memory and execute it with kernel-level privilege, researchers said. A successful attack against this vulnerability could result in a takeover of the Solaris operating environment.

The vulnerability was first discovered in 2007 and released publicly during CanSecWest 2009, according to Trustwave. A fix was issued shortly after by Sun Microsystems. Fast-forward to March 2018, when Trustwave disclosed it had found loopholes in the patch.

On July 17, Oracle released three patches to mitigate against the vulnerability as part of its July patching schedule. On Tuesday, Trustwave and Oracle publicly disclosed the vulnerability (CVE-2018-2892).

top feature image

Bluetooth Bug Allows Man-in-the-Middle Attacks on Phones, Laptops

A slew of vendors that have built Bluetooth pairing into their devices without requiring public key validation are issuing fixes for their products.

Researchers at the Israel Institute of Technology have identified a cryptography-related security vulnerability (CVE-2018-5383) in the Bluetooth specification for over-the-air short-range connectivity between devices, concerning two related Bluetooth features: Secure Simple Pairing and LE Secure Connections.

Simply put, the Bluetooth spec allowed vendors to opt out of implementing public key authentication when devices use the two features, throwing open the door to a man-in-the-middle attack. Without the authentication in place, the vulnerability comes into play: An attacker with physical proximity (within 30 meters) can gain unauthorized access via an adjacent network, intercept traffic and send forged pairing messages between two vulnerable Bluetooth devices. This could result in attackers intercepting information flowing to the devices (including two-factor authentication messages), elevation of privilege and/or denial of service.

“It is possible that some vendors may have developed Bluetooth products that support those features but do not perform public key validation during the pairing procedure,” said the Bluetooth Special Interest Group (SIG) in a short post on the issue this week, noting that the spec recommends public key validation, but previously did not require it. “To remedy the vulnerability, the Bluetooth SIG has now updated the Bluetooth specification to require products to validate any public key received as part of public key-based security procedures. In addition, the Bluetooth SIG has added testing for this vulnerability within our Bluetooth Qualification Program.”

Diving in a bit deeper into the vulnerability, the problem specifically exists in Bluetooth’s use of a device-pairing mechanism based on elliptic-curve Diffie-Hellman (ECDH) key exchange, to allow encrypted communication between devices.

“The ECDH key pair consists of a private and a public key, and the public keys are exchanged to produce a shared pairing key,” a CERT/CC advisory explained on Monday. “The devices must also agree on the elliptic curve parameters being used. Previous work on the Invalid Curve Attack showed that the ECDH parameters are not always validated before being used in computing the resulted shared key, which reduces attacker effort to obtain the private key of the device under attack, if the implementation does not validate all of the parameters before computing the shared key.”

In vulnerable implementations, CERT explained, those elliptic curve parameters are not all validated by the cryptographic algorithm implementation. Thus, a remote attacker within range can simply inject an invalid public key to determine the session key with high probability, and from there passively intercept and decrypt all device messages, and/or forge and inject malicious messages.

Bluetooth said that there’s no evidence of an exploit in the wild, and noted that a successful attack would be somewhat challenging:

top feature image

Apache, IBM Patch Critical Cloud Vulnerability

Apache and IBM have patched a critical vulnerability that allows attackers to replace a company’s serverless code with their own malicious script.

Once running, the bad code could then be used for a range of nefarious tasks, including extracting confidential customer data such as passwords or credit-card numbers, modifying or deleting data, mining cryptocurrencies or launching a DDoS attack.

The vulnerability (seen in action in this video), originally discovered by researchers at PureSec, was found in Apache OpenWhisk, the open-source serverless platform that IBM uses to run cloud functions. IBM has patched the issue, but other implementations at other vendors could also be flawed.

Serverless computing is a cloud-computing execution model in which cloud providers dynamically allocate machine resources; the name comes from the fact that the actual server management and capacity-planning decisions are completely hidden from the developer or operator.

Apache OpenWhisk executes these functions in response to events with rapid auto-scaling. It provides a programming model to create functions as cloud-native event handlers, and executes the functions automatically, inside runtime containers, as the events occur.

The PureSec threat research team demonstrated how, if the serverless function is itself insecure and could be hijacked by an attacker to remotely execute injected code, the attacker may overwrite the source code of a vulnerable function which is being executed in a runtime container.

An attacker first needs to be able to force a function to launch an HTTP request to the localhost of the container over port 8080 to be successful – which can be achieved in a multitude of ways. According to a whitepaper released Tuesday on the weakness, these include: exploiting a remote-code execution vulnerability in the action’s logic; exploiting a server-side Node.JS cross-site scripting flaw; exploiting unsafe use of eval() in different relevant runtime languages; or exploiting an SSRF vulnerability in the action’s logic.

From there, it’s possible to influence subsequent executions of the same function in the same container.

“Usually, a serverless function pops into existence, runs the code it needs to run, and then vanishes forever,” a PureSec spokesperson told Threatpost. “It does this inside a ‘container’ like (in this case) Docker, though as a user of serverless you don’t see the container or all the techie infrastructure stuff.”

PureSec added, “sometimes, the system will keep the container around for a few seconds if it’s going to run the same function again, for speed and convenience. In this case, the serverless function is the hacked function running the hacker’s code, and it keeps the container alive so that the hacked code can keep doing its thing.”

top feature image

Google Starts Labeling All HTTP Sites as ‘Not Secure’

Websites that insist on sticking with HTTP will have a public relations issue on their hands, beginning today: All of them, without exception, will be labeled as insecure by Google Chrome from now on.

Anyone using the Chrome web browser will be served up a warning message anytime they surf to an HTTP page, as part of the internet giant’s release of Chrome 68. The website will be flagged as “not secure” in a hard-not-to-notice warning label in the navigation bar. Given that Chrome is the most widely used browser in the world, the impact can be significant for web pages that haven’t migrated to HTTPS, which encrypts traffic flowing to and from a site.

The reason for the move is simple: “When you load a website over plain HTTP, your connection to the site is not encrypted,” said Emily Schechter, Chrome security product manager, in today’s blog on the move. “With HTTPS, your connection to the site is encrypted, so eavesdroppers are locked out, and information (like passwords or credit-card info) will be private when sent to the site.”

“When someone visits a website that does not use HTTPS, the entire interaction is broadcast in the clear for anyone on the network path to see,” added Josh Aas, executive director of the Internet Security Research Group, the organization behind Let’s Encrypt, in an email to Threatpost. “Furthermore, the interaction can be tampered with to include anything from ads to malware.”

To be fair, webmasters can hardly be caught unaware by Google’s policy: The plan to do this has been in the works for two years. Google announced in 2016 that it would be encouraging encryption on the web by slowly and steadily moving in on HTTP sites with warning notifications. Last year, with the January 2017 release of Chrome 56, Google started putting warnings on desktop HTTP pages with password or credit-card forms. October 2017’s Chrome 62 added “not secure” warnings for when users enter data on a HTTP page, and for any HTTP page a user visits while in the browser’s incognito mode.

Schechter said that since the announcement nearly two years ago, HTTPS usage has made “incredible progress.” Google’s latest Transparency Report showed that 76 percent of Chrome traffic on Android is now HTTPS-protected, up from 42 percent in 2016; while 85 percent of Chrome traffic on ChromeOS is now protected, up from 67 percent.

Also, 83 of the top 100 sites on the web (as ranked by Alexa) use HTTPS by default, up from 37 two years ago.

Further, to date, HTTPS certificates from automated tool Let’s Encrypt cover over 113 million websites (up from 89 million just last month), and the organization said that it’s on track to encrypt more than 150 million websites by the end of 2018.

“We expect Google Chrome’s new warnings to contribute significantly to that growth, as well as HTTPS growth on the web in general,” Aas said. “We regularly engage with hosting providers regarding current and upcoming HTTPS deployments. Hosting providers of all sizes are accelerating their plans to move websites to HTTPS as a direct result of Google Chrome 68’s user interface changes.”

While it seems a fait accompli, this isn’t the end of the effort, according to Schechter – there’s a web encryption 2.0 plan underway as well.

“Eventually, our goal is to make it so that the only markings you see in Chrome are when a site is not secure, and the default unmarked state is secure,” she explained.

Google will roll this out over time, starting by removing the “secure” wording in September with Chrome 69. In October, with the release of Chrome 70, the browser will start showing a red “not secure” warning when users start typing in data in forms on HTTP pages, to get their attention.

top feature image

Kronos Banking Trojan Resurfaces After Years of Silence

The Kronos banking trojan is back from the malware dustbin. After years of lying dormant, hackers have reworked the underlying code and are actively targeting victims in Germany, Japan and Poland.

The latest variant has incorporated a new command-and-control feature designed to work with the Tor anonymizing network, according to an analysis by Proofpoint researchers published Tuesday.

They believe that Kronos has been not only retooled, but may also have been rebranded as Osiris. That’s the name some criminals are using for a nearly identical trojan being sold on underground markets.

“While there is significant evidence that this malware is a new version or variant of Kronos, there is also some circumstantial evidence suggesting it has been rebranded and is being sold as the Osiris banking trojan,” Proofpoint said. The name would be apt: Osiris is the Egyptian god of rebirth.

Since June 27, researchers said they have observed four distinct campaigns containing malicious files that eventually lead to the downloading of the Kronos/Osiris trojan.

The Kronos banking trojan was first discovered in 2014 and quickly made a name for itself as an adept malware capable of stealing credentials and using web injects for  banking websites. The trojan also included a Ring3 rootkit to help defend it against other trojans. But in 2016, the once-formidable banking trojan dropped off researchers’ radar screen.

In 2017, Kronos once again made headlines when the Federal Bureau of Investigation accused WannaCry-slayer Marcus Hutchins of building the banking trojan — but actual activity of the malware remained limited.

Now, recent malware-laced spam campaigns in Germany have targeted customers of financial firms with email subject lines that translate into English as “Updating our terms and conditions.” In these offensives, malware samples used the URL “http://jhrppbnh4d674kzh[.]onion/kpanel/connect.php” as its C&C.

“The Word documents contained macros that, if enabled, downloaded and executed a new variant of the Kronos banking trojan. In some cases, the attack used an intermediate smoke-loader,” researchers wrote. A smoke-loader is the name of a small application typically used to download additional malware in an attack.

top feature image

Massive Malspam Campaign Finds a New Vector for FlawedAmmyy RAT

A widespread spam campaign from the well-known financial criminal group TA505 is spreading the FlawedAmmyy RAT using a brand-new vector: Weaponized PDFs containing malicious SettingContent-ms files.

The SettingContent-ms file format was introduced in Windows 10; it allows a user to create “shortcuts” to various Windows 10 setting pages.

“All this file does is open the Control Panel for the user [control.exe],” explained SpecterOps researchers in a recent posting on the format. “The interesting aspect of this file is the <DeepLink> element in the schema. This element takes any binary with parameters and executes it. What happens if we simply substitute ‘control.exe’ to something [malicious]?”

The answer to that question is that the substituted script, when opened, executes any command automatically, including cmd.exe and PowerShell, with no prompt to the user – making the format a perfect conduit for malware.

This approach code also flies under the radar, and the maliciously crafted files simply bypass certain Windows 10 defenses such as Attack Surface Reduction (ASR) and detection of OLE-embedded dangerous file formats.

Of course, getting victims to open a funky file format attached to an email could be a challenge, so bad actors have started embedding these into more innocent-looking attachments. Accordingly, researchers at SpecterOps in June saw campaigns abusing the SettingContent-ms file format within Microsoft Word documents. Earlier this week however, Proofpoint researchers observed the approach evolving, and being used with PDF documents – a previously unknown technique.