Intelligence collected from public information online could be impacting traditional warfare and altering the calculus between large and small powers.

An open source panopticon—from commercial big data aggregation to information infrastructure across mobile, smart devices, and social media—is reshaping the way intelligence is collected and used in conventional war.

Open source intelligence is information that can be readily and legally accessed by the general public. It was used in war and diplomacy long before the internet—alongside information stolen or otherwise secretly obtained and closely held. But its prevalence today means what was once cost-prohibitive to many is now affordable to myriad actors, whether North Korea, the CIA, journalists, terrorists, or cybercriminals.

One consequence of widely available open source information is that anonymity is eroding, not only for ordinary civilians, but also for members of law enforcement, military, and the intelligence community. Even missing information can alert an adversarial spy service, says a former US intelligence official who spoke on background. When the US State Department unfolded a public diplomacy strategy in 2008 that emphasized the use of social media, a foreign counterpart joked to the former US intelligence official that CIA officers, working under nonofficial cover at US embassies, were easily deduced because they lacked Facebook profiles. The US government has a gargantuan effort underway to address similar issues brought on by an absence or expectation of digital exhaust associated with intelligence officers’ cover identities.

When it comes to modern intelligence collection, closed societies like North Korea, Russia, and Iran have an advantage against open ones. Both secrecy and transparency—or the control of information, whether by individuals or governments—are integral to the freedom and security of those individuals and societies. Closed societies can collect an open one’s information with ease, all the while preventing access to similar information from domestic political opponents or hostile foreign actors.

But too much secrecy on the part of governments and militaries—including those of Russia’s Vladimir Putin—can also prevent them from knowing themselves, which may contribute to strategic blunders. Information technology, by its nature, disintegrates boundaries. It erodes barriers to markets across sectors and societies: from journalism to intelligence, crime to terrorism—and now it seems, with Russia’s invasion of Ukraine, conventional war.

Intelligence isn’t just information, says Jeff Rogg, a historian of US intelligence whose work focuses on civil-intelligence relations. The objective of intelligence, compared to just information, is obtaining or maintaining an advantage over one’s adversaries—whether that intelligence is secret or open source. This principle is at play when the Biden administration declassifies intelligence in an unprecedented manner in order to counter Russian misinformation or shares secret intelligence with Ukrainian counterparts.

“Given the emphasis placed on open sources in the war in Ukraine, it’s easy to forget how successful intelligence outcomes can also depend on secrecy, and even a bit of deception. Attributing successes in Ukraine to open sources can also offer a cover of sorts for more closely held sources and methods,” says Rogg.

British scholar Matthew Ford, coauthor of an upcoming book on the impact information infrastructure and connected devices have on conventional military conflicts, calls the phenomenon “radical war.”

Ford says that the high level of mobile connectivity among Ukrainians and a notable absence of combat footage from smartphones and headcams, especially in the early phases of the war, suggest an effective information operation may be underway. “No doubt the Ukrainians fear such images will reveal their tactics, techniques, and procedures,” says Ford. So Ukrainians may simply be censoring themselves.

Social media platforms and cell phones are also a force multiplier for traditionally weaker military powers, like Ukraine, especially when it comes to coordinating intelligence collection for targeting activities. “Targeting information is now being exchanged online,” Ford says. “Successful kills have been celebrated on Telegram. Chatbots have been established, helping Ukrainians share target coordinates with their smartphones. Identifying targets doesn’t involve complex military systems; it works from civilian information infrastructures.”

“The problem with crowdsourced intelligence in a war like Ukraine is standardizing the reporting,” Ford says. For example: “You want to be able to identify the vehicle, geo-locate it, then map against any available signals or satellite imagery, or other collection disciplines, fusing it into actionable target information.”

The Russian invasion of Ukraine is not only the 21st century’s first conventional war in Europe, it is the “most digitally connected in history,” according to Ford. “If the Ukrainians can make that intelligence actionable quicker than the Russians, they can use their limited remote fires, artillery, drones, and maybe even missiles or air power effectively. The objective, therefore, is to find, fix, and finish Russian forces more quickly than the Russians can do this themselves.”

When Russia launched its full-scale invasion in late February, the US, its allies, and Russia concluded that Ukraine’s forces were asymmetrically disadvantaged against Putin’s endowed and historically brutal counterpart. US officials expected the country to fall in days. Yet despite the US’s monumental success predicting Russia’s intentions and plans and offering warnings, American intelligence agencies incorrectly assessed Ukraine’s prospects—the current subject of an internal review.

Facing the full onslaught of Russia's armed forces, Ukraine’s military resilience may even have come as a bit of a surprise to Ukrainians themselves, Ford suspects. Yet mistaken judgments about the expected balance between strong and weak powers, accompanied by strategic surprise, may be a common occurrence in the information age. Before the acknowledged role of social media in fueling the Arab Spring, or the reported significance of thumb drives in more recent counterintelligence failures—telecommunications, open source infrastructure, and cheap and accessible consumer technology have impacted the parity calculus for state and non-state actors alike.

Indeed, it was the worldwide growth of telecommunications in the 1990s that empowered Al-Qaeda to conduct its successful covert military attacks on US soil on September 11, 2001. But in the run-up to those attacks, the US Department of Defense hadn’t drafted a net assessment on the military or intelligence capabilities of what was later described by the 9/11 Commission as America’s “most dangerous foreign enemy.” The concept was unimaginable then, but it shouldn’t be now.

Similarly, the intelligence community had not authored a national estimate that comprehensively evaluated or articulated the strategic threat posed by Al-Qaeda before its 2001 attack. This category of cognitive bias is called the “paradox of expertise.” Genuine experts may communicate incredible nuance and understanding of a subject but overlook indicators of seismic changes within the domains of their knowledge.

It’s also possible to make analytical errors by overstating or inflating the impact or outcomes of technology and information on civil society—or any domain—including conventional war. The internet, which promised us a techno-utopian commune of open source information, has arguably turned large swaths of civil society into psychedelic hellscapes, much like the Charles Manson murders after the Summer of Love.

Civilian noncombatants’ use of open source platforms and consumer devices in support of hostile military actions raise serious questions about blurred lines between civilian and combatant—lawful or otherwise—leading to the same subjects becoming legitimate targets or tried for espionage under the laws of war. Civilians are legally protected under international humanitarian law, as long as they are not party to military conflicts.

According to recent reports, US intelligence support led to the successful targeting of Russian generals and the _Moskva_, Russia’s flagship in the Black Sea. “One of the intelligence concerns people have voiced is that these leaks unnecessarily raise the risks of escalation,” Rogg says. “But consider the Javelins, Stingers, and military hardware we are publicly providing. The US and its allies are fighting an overt—as compared to covert—proxy war against Russia. That’s one of the key distinctions in this conflict from, for example, US support to the mujahideen in Afghanistan in the 1980s, which is one of the popular comparisons you read about today: The US is taking a risk by abandoning some of the hallmarks of intelligence and advantages of covert action, like plausible deniability. That being said, there is still plenty that we do not know. Putting aside all the reporting, leaks, and official disclosures, the exact role and impact of US intelligence in Ukraine will be a source of study and debate for years to come.”

Open Source Intelligence May Be Changing Old-School War

A spyware vendor called Cytrox was found to be using several zero-day vulnerabilities in Google's Chrome browser and the Android kernel component. 
The post Zero-day vulnerabilities in Chrome and Android exploited by commercial spyware appeared first on Malwarebytes Labs.

The Google Threat Analysis Group (TAG) has revealed that of the nine zero-day vulnerabilities affecting Chrome, Android, Apple and Microsoft that it reported in 2021, five were in use by a single commercial surveillance company.

Did I hear someone say Pegasus? An educated guess, but wrong in this case. The name of the surveillance company—or better said, professional spyware vendor—is Cytrox and the name of its spyware is Predator.

**Google**

TAG routinely hunts for zero-day vulnerabilities exploited in-the-wild to fix the vulnerabilities in Google’s own products. If the group finds zero-days outside of its own products, it reports them to the vendors that own the vulnerable software.

Patches for the five vulnerabilities TAG mentions in its blog are available. Four of them affected the Chrome browser and one the Android kernel component.

**Vulnerabilities**

By definition, zero-day vulnerabilities are vulnerabilities for which no patch exists, and therefore potentially have a high rate of success for an attacker. That doesn’t mean that patched vulnerabilities are useless to attackers, but they will have a smaller number of potential targets. Depending on the product and how easy it is to apply patches, vulnerabilities can be useful for quite a while.

In the campaign uncovered by TAG, the spyware vendor used the zero-days in conjunction with other already-patched vulnerabilities. The developers took advantage of the time difference between the availability of patches for some of the critical bugs, as it can take a while before these patches are fully deployed across the Android ecosystem.

TAG says Cytrox abused four Chrome zero-days (CVE-2021-37973, CVE-2021-37976, CVE-2021-38000, and CVE-2021-38003) and a single Android zero-day (CVE-2021-1048) last year in at least three campaigns conducted on behalf of various governments.

**Cytrox**

TAG is actively tracking more than 30 vendors with varying levels of sophistication and public exposure selling exploits or surveillance capabilities to government-backed actors. Cytrox is one of these vendors, along with the NSO Group—undoubtedly the best known one among them and responsible for Pegasus spyware.

Citizenlab at the University of Toronto published information about Cytrox in December 2021. It says that Cytrox describes its own activities as providing governments with an “operational cyber solution” that includes gathering information from devices and cloud services. It also says it assists with “designing, managing, and implementing cyber intelligence gathering in the network, enabling businesses to gather intelligence from both end devices as well as from cloud services.”

Cytrox reportedly began life as a North Macedonian start-up and appears to have a corporate presence in Israel and Hungary. As such, Cytrox is believed to be part of the so-called Intellexa alliance, a marketing label for a range of mercenary surveillance vendors that emerged in 2019. The consortium of companies includes Nexa Technologies (formerly Amesys), WiSpear/Passitora Ltd., Cytrox, and Senpai, along with other unnamed entities, purportedly seeking to compete against other players in the cyber surveillance market such as NSO Group (Pegasus) and Verint.

**Government spyware**

Spyware packages such as Predator and Pegasus create problematic circumstances for the security teams at Google, Apple, and Microsoft, and it seems like they will not stop any time soon.

Whatever arguments these vendors use about how they are working for governments, and therefore not doing anything illegal, we all know the legitimacy of some governments lies in the eye of the beholder. And it is not always easy to find out who actually controls the data received from the spyware.

It is for good reason that the European Data Protection Supervisor (EDPS) has urged the EU to ban the development and deployment of spyware with the capabilities of Pegasus to protect fundamental rights and freedoms. The EDPS argues that the use of Pegasus might lead to an unprecedented level of intrusiveness, threatening the very essence of the right to privacy, since the spyware is capable of interfering with the most intimate aspects of our daily lives.

Zero-day vulnerabilities in Chrome and Android exploited by commercial spyware

An in-depth look at the attack chain used by an unknown APT group that has launched four campaigns against Russian targets since February.
The post Unknown APT group has targeted Russia repeatedly since Ukraine invasion appeared first on Malwarebytes Labs.

An unknown Advanced Persistent Threat (APT) group has targeted Russian government entities with at least four separate spear phishing campaigns since late February, 2022.

The campaigns, discovered by the Malwarebytes Threat Intelligence team, are designed to implant a Remote Access Trojan (RAT) that can be used to surveil the computers it infects, and run commands on them remotely. The malware uses a number of advanced tricks to hide what it does and how it works, but our analysts have been able to reverse engineer the malware, reveal its inner workings, and uncover some clues about its possible origins.

Attribution is always difficult, and there is no shortage of countries or agencies with an interest in getting covert access to Russian government computers—and the recent invasion of Ukraine has simply increased the stakes. Although our analysis and attribution efforts are ongoing, we have discovered some indicators that suggest the threat actor may be a Chinese group.

**The campaigns**

The APT group has launched at least four campaigns since late February, using a variety of lures, detailed below.

**1\. Interactive map of Ukraine**

The threat actor started this campaign around February 26, 2022, and distributed its custom malware with the name interactive_map_UA.exe, trying to disguise it as an interactive map of Ukraine. This campaign began a few days after Russia invaded Ukraine, which shows the threat actor was monitoring the situation between Ukraine and Russia and took advantage of it to lure targets in Russia.

**2\. Log4j patch**

In this campaign the threat actor packaged its custom malware in a tar file called Patch_Log4j.tar.gz, a fake fix for December’s high-profile Log4j vulnerability.

This campaign ran in early March and was primarily aimed at RT TV (formerly Russia Today or Rossiya Segodnya, a Russian state-controlled international television network funded by the Russian government). The APT group had access to almost 100 RT TV employees’ email address.

The emails were sent with the subject “Ростех. ФСБ РФ. Роскомнадзор. Срочные сиправления уязвимостей”, which translates into “Rostec. FSB RF. Roskomnadzor. Urgent Vulnerability Fixes”. (Rostec is a Russian state-owned defense conglomerate founded by Putin.)

The emails also come with a number of image files and a PDF attached, perhaps to make the email less suspicious, and to bypass any systems that flag emails by number of attachments.

A spear phishing email from an unknown APT group claims to have “urgent vulnerability fixes”

The PDF attachment—О кибербезопасности 3.1.2022.pdf—pretends to be from the “Ministry of Digital Development, Telecommunications and Mass Communications of the Russian Federation”. It contains instructions about how to execute the fake patch, as well as a bulleted list of security advice such as “Use two-factor authentication”, “Issue separate credit cards for purchases”, and “Use Kaspersky antivirus”.

A PDF attachment tries to build trust with security advice and instructions on how to run the fake Log4j patch

In a confident demonstration of just how little attention people pay to such lists it ends “Do not open or reply to suspicious emails.”

The list even includes a link to a page on VirusTotal that proclaims in bright green letters that “No security vendors and no sandboxes flagged this file as malicious”. This is just another effort to convince the victims that the attachment is not malicious—the file on VirusTotal has nothing to do with the attachment and appears to be a legitimate OpenVPN file.

The PDF attachment links to a VirusTotal entry for an unrelated file

In another effort to build trust, the spear phishing email links to the website rostec.digital, a domain registered by the threat actor, hosting a site made look like the official Rostec website.

This email also contains links to fake Instagram and Facebook accounts. Interestingly, the threat actor created the Facebook page in June 2021, nine months before it was used in this campaign. This was probably an attempt to attract followers, to make the page look more legitimate, and it suggests the APT group were planning this campaign long before the invasion of Ukraine.

The rostec.digital website  

The rostec.digital facebook account

The rostec.digital Instagram account

**3\. Build Rostec**

The Rostec defense conglomerate also appears in the third campaign. This time the threat actor used the file name build_rosteh4.exe for its malware—an apparent attempt to make it look like software from Rostec.

**4\. Saudi Aramco job**

The most recent campaign occured in mid April and used a Word document containing a fake job advert for a “Strategy and Growth Analyst” position at Saudi Aramco as a lure.

(We also discovered a self-extracting archive file that belonged to this campaign—the archive file used a Jitsi video conferencing software icon as decoy, and created a directory named Aramco under C:\ProgramData.)

Although the job advert is written in English, it also contains a message in Russian, asking users to enable macros.

A malicious job advert urges Russian readers to enable macros

The document uses remote template injection to download a macro-embedded template, which executes a macro that drops a VBS script called HelpCenterUpdater.vbs in the %USER%\Documents\AdobeHelpCenter directory.

The template also seems to do a redundant check for the existence of %USER%\Documents\D5yrqBxW.txt and only if it doesn’t exist, will it drop the script and execute it.

Macros embedded in the remote template

The obfuscated HelpCenterUpdater.vbs script drops another obfuscated VBS file named UpdateRunner.vbs and downloads the main payload—a DLL named GE40BRmRLP.dll—from its command and control (C2) server. (Interestingly, some anti-analysis code, and code responsible for persistence, seems to be commented out in UpdateRunner.vbs and isn’t executed.)

In another payload related to this campaign, the script seems to drop an EXE instead of a DLL, but after analyzing both it seems they share the same code.

Deobfuscated HelpCenterUpdater.vbs

The job of the UpdateRunner.vbs script is to execute the DLL through rundll32.exe.

Deobfuscated UpdateRunner.vbs

The malicious DLL contains the code that communicates with the C2 server and executes the commands it receives from it.

The attack chain for the Saudi Aramco-themed APT campaign

The malware, which is common to all four campaigns, is explained in detail in the next section.

**Payload analysis**

This analysis focuses on the GE40BRmRLP.dll payload from the Saudi Aramco campaign, but the malware used in all four campaigns is essentially the same, with small differences in the code.

The DLL is heavily obfuscated and most of the library functions are statically linked. IDA is barely able to recognize any functions, though it was able to recognize a few that indicate the DLL was most likely compiled with LLVM. The DLL’s original name is supposed to be simpleloader.dll, as we can see after analyzing it a bit.

The DLLMain function from GE40BRmRLP.dll

Before we dive into the functionality and capabilities of this malware, let’s look at various methods it uses to make the analysis difficult for us.

**Anti-analysis techniques****Control Flow Flattening**

All of the samples used in these campaigns use control flow flattening heavily, a technique that flattens the nested structure of a program, making analysis very difficult. We used the D810 plugin for IDA which has the capability to deobfuscate flattened code and make the decompilation more readable.

Although there are many tools that can perform control flow flattening, in this case we suspect OLLVM—an obfuscator for LLVM—was used. The different samples had different levels of flattening and OLLVM allows users to specify this. Additionally we also saw what looks like the Bogus Control Flow LLVM pass being used.

Control Flow Flattening used by the malware

**String obfuscation**

The payload’s strings are obfuscated with simple XOR encoding. The decode_string function which is used to decode a string takes 3 arguments: The encoded string, the destination of the decoded string, and the byte that is used while decoding the string.

Each string is decoded every time it’s required by the malware.

The decode_string function from GE40BRmRLP.dll

**Command and control**

Before contacting its C2 server the malware derives an ID which is unique to every machine, which could be used to differentiate infections. It uses the data from the following APIs to construct the ID:

*   GetFileAttributesA on the C:\Windows directory
*   GetComputerNameA
*   GetVolumeInformationA on the C:\ drive

It then calculates a hash of this data using the Blake2b-256 algorithm and sends it when it makes the first contact with its C2.

Deriving the ID

The C2 address is decoded every time the malware sends a request. To communicate with the C2 the malware uses GET requests in the form url/?wSR=_data_, where _data_ contains the encoded information.

Interestingly Any.run and Fiddler fail to capture the HTTPS requests made by the malware. To make them, the malware doesn’t use any library functions but instead implements everything over raw sockets, and it uses the WolfSSL library to implement SSL itself. Our analysis also uncovered traces of http-parser from ZephyrOS. The certificate used for the SSL communication is stored inside the binary as chunks of encoded strings. Initially the malware decodes this data and stores it. Later, while making the HTTPS request, it loads this data using WolfSSL’s loadX509orX509REQFromBuffer.

After making every request the malware sleeps for a random amount of time.

HTTPS GET request

Based on the response to the above request, the malware decides which of command to execute:

1.  **getcomputername**. This retrieves the computer name using GetComputerNameA and sends a response to the C2 containing the unique id and the computer name.
2.  **upload**. This receives a file name and file contents from the C2 which it writes to the local file system.
3.  **execute**. This receives a command line instruction from the C2 and executes it using CreateProcessA. If the command is successful then the malware sends the UID with the “OK” string to the C2, or the output of GetLastError if it fails.
4.  **exit**. This is used to terminate the malware process.
5.  **ls**. This command uses a directory name from the C2, or the name of the current directory if one isn’t provided. It uses the FindFirstFile and FindNextFile function to retrieve a list of all the files under the directory and sends it back to the C2.

The upload command

The List Files command

**Attribution**

Attribution is difficult, and threat actors are known to use indicators from other groups as false flags. The attribution of the APT behind these campaigns is ongoing, but based on the infrastructure used we assess with low confidence that this group is a Chinese actor.

All of the C2s are from BL Networks, which has been used by Chinese APTs in the past. Also, we discovered infrastructure overlap between the malware we analyzed and the Sakula Rat malware used by the Deep Panda APT.

Infrastructure overlap between Sakula RAT and the malware analzed in this article

Another interesting indicator we found was that the macro used in the Aramco campaign is almost identical to some macros used by TrickBot and BazarLoader in the past. We think the actor may have used the same macro builder to generate its macro, and they may have used it as a false flag. There are some other weak indicators, such as WolfSSL, which has been used by Lazarus and Tropic Troopers, but they are not enough to help attribute the attack to any specific actor.

Malwarebytes customers were proactively protected against these campaigns thanks to our heuristic detection engines.

**IOCs****C2 Domains**

windowsipdate\[.\]com  
microsoftupdetes\[.\]com  
mirror-exchange\[.\]com

**C2 IPs**

168.100.11.142  
192.153.57.83  
45.61.137.211  
206.188.197.35

**Download Domain**

fatobara\[.\]com

**Download IP**

91.210.104.54

****Hashes****

Name

Hash

Final payload

cbde42990e53f5af37e6f6a9fd14714333b45498978a7971610acb640ddd5541  
86ecd536c84cec6fc07c4cb3db63faa84f966a95763d855c7f6d7207d672911e  
917820338751b08cefc635090fc23b4556fa77b9007a8f5d72c11e0453bfec95  
22bdc42a86d3c70a01c51f20f5b7cfb353319691a8102f0fe3ea02af9079653e  
12c20f9dbdb8955f3f88e28dc10241f35659dbcd74dadc9a10ca1b508722d69a  
3f16055dc0f79f34f7644cae21dfe92ffc80f2c3839340a7beebd9436da5d0eb  
f5658588c36871421f287f12e7e9ba5afba783a7003da1043a9c52d10354b909  
ca95e8a8b6fb11b5129821f034b337b06cdf407fa9516619f3baed450ac1cf2d  
bac1790efe7618c5b2b9e34e6e1d36ec51592869bcc5fb304dd7554c32731093  
5d039f4368f88a2299be91303c03143e340f700f1fc8aa0a8cdbfbc5a193c6be

patch\_Log4j.tar.gz

4b622d63e6886b1430f6ca9cba519cbefde60cd8b6dbcade7c3a152c3930e7c7

PDF attachment

f4db6fa3a83052152b5d16dc6a4e9749afafc026612ff5c3ad735743736ac488

Emails

0625566ec55f0a083d1c1a548a2631502f17e455066b29731e29d372918e6541 0925b3c05cef6d3476a97b7d4975e9e3ceefedf62f42663b9c02070e587b3f2d 111fef44ba63f11279572f1e7e4d6ce5613ef8fe3b76808355cdcbed47b49fec 1c886a9138f3b0e0b18f1c0da83719a9b5351db7ce24baa13c0e56ef65d96d02 1fb0cd76ec5ae70f08a87f9e81cb5e9b07f9b3306772ae723fa63ff5abfa0d07 27d19efedb6a7c8d3c65fe06fd5be9c3e236600e797e5058705db1e2335ec2ad 310fa9c65aa182a59e001e8f61c079e27d73b8eb5f8f8965509cb781d97ba811 3627b37b341efa0b36352d76480dce994f481e672ebf9fa2da114a1339cf6c01 3655420f72d0c14cfb113ccb53e9ac85b87883913c3844b3e0bfb7bd7230a9bd 3b2ef76ec2eb3b4db4b7efe14d88c5338f1dc4eb9a9cf309989362d193c25403 3e9254d8cb25b2abf4fb755feaaf41c0059c68067e64de01a9242e5d9e47ab33 3ff96e73aeb0419df67bc5fec786a4dc82e4a9051274b4fc3cbc3ae3af7fdf94 44118322165be32de86569972e9f599a3c79a2336ca6f76c29861b40905cd067 4b6b0c29ece1c4719ec4d5186fb6247603fa1f03bd473bf6ef6367995e8c1121 4f28db1131ace2fce96e84172e0a861eb471ea054799e1132eb4945e4dca550b 4f8c2079ac98a3e8e085be8e88ff7b53ea70cb131cba4bfd2784e391d24c27e9 5a662050df51863575700a8e21efe605f4e789404d4bb53b4299f32b93e8d20f 5aa0a15e052fea2a2d445940ef751ddf3d3ae7c43c095a738b9bd603efc7df8b 5b9c7fe8ee5756dbd8563b3efe8dbc0966ad9044ff223b8797940f9e4e47333e 5ccf98699b96c811f4dab768cf486dc0f31b098dba30e031ba4ab2a5a5a3aba8 7ee7b2193b1e53f93dc2ed573d8f927cfa0916ccf111ff35faef9c4b153456f2 80a3de79f6c859d6c4667f705588c7c254d24fca2f44704123a2ba38e7c285a9 810d6566d9879c10a6a8581bb6ea6bed83a14a869383ad7e1ee16eadfd5bbb54 811827026414bdd400257cd3f048a1c75a2b211d02ac790510b800baa0702de4 81f24d1c310214b8f66345f250a6d5493e5e1cdf06d39d18a96cd9f93a1e7655 ac328efa54b6dd4497ba5dc6195474b8b9e5a7bcd32d5733e5006be9bbd0dc22 b63ef28fc1b0b1180fe9f476fe2ef3970b9928b009354e996bb2bf4ece223031 b99580152dde60622c1a962cd7cee1834d0ee86490785ac02d8ee51b73be008f c9623e83d875d6b9ca1a80087151b59a4037159c605ee92c6c795252ccf89596 cd277299ed849de71e88f698c1c06b0cfa65f166b0e90fc620aa50f6efe70161 d4062c6fd3813299ac721309fe0385a5337cea8b8e3605b05458467aeb23d8c0 e19b7dfe0e693c468c73f0a9e4c751216787daeff7d933cedcc10c932bd2835e e444303f1888b1ee5eeb69a0c4c3372b0cd2276b6987b0b18ea2267ff7ba19ad f15d90da5e253aaf570d29ffb9bf87ce7d8292b953d13e5a0f86b8671a4c57e7 fa800e6e16444894455b2a8f9e245efbe8b298fc8af9d7f8e155bb313ca9e7bb fc4af16fed48bd3a029ce8bfc4158712f9ab0cd8b82ca48cb701923d0a792015

Unknown APT group has targeted Russia repeatedly since Ukraine invasion

app/models/user.rb in Mastodon before 3.5.0 allows a bypass of e-mail restrictions.

CVE-2022-31263: Release v3.5.0 · mastodon/mastodon

NIST may be on the brink of revealing which post-quantum computing encryption algorithms it is endorsing, solidifying commercial developments like QuProtect.

Cybersecurity experts are awaiting the imminent announcement from the National Institute for Standards (NIST) of its recommended post-quantum computing (PQC) encryption algorithms, an important milestone in a years-long process that started back in 2016 with 82 candidates. NIST has signaled it will reveal its decision imminently — possibly just before or during the RSA Conference in San Francisco in two weeks, amid a swirl of new activity in the field of quantum computing.

The PQC algorithms would join RSA and elliptic curve cryptography (ECC) as a new generation of NIST-recommended encryption standards. The PQC algorithms promise to enable encryption that is exponentially more powerful than current standards, which will become essential when quantum computers are available for commercial use.

Once NIST reveals which four algorithms it is endorsing, the next phase of drafting standards will begin. That process is expected to take roughly a year. But the pending decision will establish which algorithms to focus on. While the NIST selection will allow stakeholders to apply them to their offerings, many providers say that is just one part of the solution. Several startups focused on addressing PQC are now coming out of stealth. The latest came last Thursday, when QuSecure, a San Mateo, Calif.-based company formed three years ago, officially launched both itself and its first PQC product, called QuProtect. QuSecure describes QuProtect as an orchestration platform that can protect data in transit and at rest encrypted with the new PQC algorithms.

**A 'Perfect Storm' for Quantum Computing**

NIST's selection, until recently considered at least a year away, would come amid a perfect storm unfolding this month in quantum computing, all signaling that CISOs should accelerate their PQC strategies. Recent disclosures portend that quantum computing could become commercially available sooner than once thought likely. Notably, IBM two weeks ago revealed that it will release a 433-qubit processor called IBM Osprey by the end of this year, more than a threefold increase from IBM Eagle, a 127-qubit processor introduced in November 2021. IBM's updated roadmap calls for the introduction of a 1,000-qubit processor next year called IBM Candor. In three years, IBM plans to deliver a multi-cluster offering capable of exceeding 4,000 qubits.

"By 2025, we will have effectively removed the main boundaries in the way of scaling quantum processors up with modular quantum hardware and the accompanying control electronics and cryogenic infrastructure," Jay Gambetta, VP of quantum computing and an IBM Fellow, explained in a May 10 blog post. During that same week, D-Wave Systems announced the availability of its Advantage quantum computer via the Leap quantum cloud service, a part of the University of Southern California-Lockheed Martin Quantum Computing Center hosted at USC's Information Sciences Institute (ISI).

After the creation of Shor's algorithm in 1994, researchers realized that once quantum computers arrive with an abundant level of scale and precision, they will be able to break current forms of encryption. Besides RSA and ECC, quantum computers are expected to break the long-trusted Diffie-Hellman key exchange algorithm used for modern cryptographic communications including SSL, TLS, PKI, and IPsec.

Meanwhile, efforts to provide protections from quantum computing is accelerating. The recent White House directives emphasized that the government and industry should move forward with NIST's standards as well as calling for swift passage of the Bipartisan Innovation Act, legislation reintroduced last year as the Endless Frontier Act by US Senate Majority Leader Chuck Schumer, Senator Todd Young (R-IN), Representative Ro Khanna (D-CA), and Representative Mike Gallagher (R-WI). The bill seeks to boost funding in research and the advance of technology deemed critical to US national security, which includes artificial intelligence, PQC, and semiconductors.

Following the White House directive, the US House of Representatives Oversight and Government Reform Committee on May 11 unanimously passed the Quantum Computing Cybersecurity Preparedness Act, a bill proposed by US Representative Nancy Mace (R-SC) seeking to advance the migration of federal government IT systems with PQC capabilities. The legislation now sits before the House for consideration.

**Building QuProtect**

QuSecure was founded by chairman and COO Skip Sanzeri, CEO Dave Krauthamer, and chief product officer Rebecca Krauthamer, who is also a member of the World Economic Forum's Global Future Council on Quantum Computing.

Sanzeri tells Dark Reading that roughly 15 customers are now piloting QuProtect, including several branches of the US Department of Defense and large enterprise businesses. The only commercial customer QuSecure has permission to reference is Franklin Templeton, the New York-based diversified investment firm with roughly $1.5 trillion in assets under management as of April 30, which is best known for its large mutual funds. QuSecure is incubated within Franklin Templeton, which is also an investor in the company.

While Franklin Templeton declined to comment on its QuProtect pilot, Sanzeri says it is currently in beta there. "We are moving to the next step to a broader rollout," Sanzeri says. While Sanzeri said he was restricted in the amount of detail he could offer, it has established the quantum communications link between its servers and select institutional customers. The technology doesn't require the customers to add anything on their end, he says.

The QuProtect communications channels can run on servers on premises and in the cloud, Sanzeri adds. Eventually, it will run on network switches as well, according to Sanzeri, who says QuSecure has been in talks with players including Cisco, Fortinet, Juniper Networks, and Palo Alto Networks. "The switch providers are very standards based," Sanzeri says. "And one of the reasons why they haven't necessarily adopted this yet, across the board is because NIST hasn't finalized their standards. But once they do, then I think the switch providers will all come along nicely."

QuProtect provides a secure communications channel designed to protect any node on a network and is designed to use any of the NIST-approved PQC algorithms. Sanzeri claims QuSecure is the first company that is offering a complete PQC platform. "There are some point solutions out there that might be focusing on, say, quantum random number generation, or possibly just on cryptography," Sanzeri says. "And we think that is fine. However, it's not enough. If you're going to protect the enterprise, you need to be able to protect holistically."

Vincent Berk, chief strategy officer of QuantumXchange, which provides software that uses PQC keys shared on two specific endpoints, disputes QuSecure's claim of being the only company developing a complete offering. "To claim you're the first one that brings post quantum cryptographic solutions to the entire world, I can make that exact same claim for QuantumXchange, and we can start bickering over what we consider post quantum hard," Berk says.

Nevertheless, Berk, who joined QuantumXchange earlier this year after serving as CTO and chief security architect at Riverbed Technology, believes the QuSecure has a viable offering. "What I think they're doing a great job of is they're trying to make it as easy as possible to get you to know that you can trust your new cryptographic algorithms are working for you," Berk adds.

QuSecure Carves Out Space in Quantum Cryptography With Its Vision of a Post-RSA World

The PyPI "pymafka" package is the latest example of growing attacker interest in abusing widely used open source software repositories.

Public repositories of open source code are a critical part of the software supply chain that many organizations use to build applications. They are therefore an attractive target for adversaries seeking to distribute malware to a mass audience.

The latest case in point is a malicious package for distributing Cobalt Strike on Windows, macOS, and Linux systems, which was uploaded to the widely used Python Package Index (PyPI) registry for Python application developers. The "pymafka" package has a name that's very similar to "PyKafka," a popular Apache Kafka client for Python that has been downloaded more than 4.2 million times so far.

More than 300 users were tricked into downloading the malicious package, thinking it was the legitimate code, before researchers at Sonatype discovered the issue and reported it to the PyPI registry. It has since been removed, but applications that incorporated the malicious script remain a threat.

**Second Typosquatting Incident in a Month**

The incident marks the second typo-squatting incident involving the Apache Kafka project that Sonatype researchers uncovered this month. Earlier, they discovered a package on PyPI that had the same name as a Kafka-related Python project on GitHub called "karaspace." Though the malicious package on PyPI had the same name as the legitimate project, it was designed to steal IP addresses, user names, and other information for fingerprinting devices on which the package was installed.

In a blog Friday, Sonatype described pymafka as designed to detect the platform on which it is installed and then embed an OS-appropriate version of a Cobalt Strike beacon on the device. Cobalt Strike is often used maliciously for lateral movement within a target network environment.  

Sonatype said it observed the executables being downloaded from an IP address associated with cloud-hosting provider Vultr. Once installed on a system, the beacon attempts to communicate with a China-based IP address assigned to Alibaba. 

"Less than a third of antivirus engines detected the samples as malicious at the time of our submission to VirusTotal, although that's still a better detection rate than the zero-detections seen in some of our earlier discoveries," according to Sonatype.

**Blind Trust**

The pymafka incident is the latest in a growing number of security incidents involving PyPI and other public repositories. For instance, last November researchers from JFrog discovered 11 malicious Python packages on PyPI. In July, they discovered malicious PyPI packages attempting to steal credit-card data and other information from some 30,000 systems on which the packages had been installed. The same month, a Japanese researcher reported a security issue that gave attackers a way to remotely execute malicious code on the registry.  

"Developers are blindly trusting repositories and installing packages from these sources, assuming they are secure," JFrog warned last year. "Sometimes malware packages are allowed to be uploaded to the package repository, giving malicious actors the opportunity to use repositories to distribute viruses and launch successful attacks on both developer and \[continuous integration/continuous delivery\] CI/CD machines in the pipeline."

Concerns over the growing attacker interest in public repositories have prompted several security initiatives at PyPI in recent years. These include the addition of two-factor authentication as a log-in option and API tokens for uploading software to the registry, a dependency resolver to ensure the pip package installer installs the right versions of package dependencies, and creating databases of known Python vulnerabilities in PyPI projects.

Concerns over software supply-chain security has prompted other, more strategic initiatives as well. Earlier this month, the National Institute of Standards and Technology (NIST) updated its cybersecurity guidance with new recommendations for addressing risks in the software supply chain. MITRE, too, has released a prototype framework called System of Trust that organizations can use to evaluate the security practices of service providers and suppliers in the software supply chain.

Malicious Python Repository Package Drops Cobalt Strike on Windows, macOS & Linux Systems

Windows OS can be configured to overlay a “language bar” on top of any application. When this OS functionality is enabled, the OS language bar UI will be viewable in the browser alongside the AVEVA InTouch Access Anywhere and Plant SCADA Access Anywhere applications. It is possible to manipulate the Windows OS language bar to launch an OS command prompt, resulting in a context-escape from application into OS.

CVE-2022-1467: Support | Cyber Security Updates

This week on Lock and Code, we speak with Whitney Merrill about why it is so difficult to get your own data from a company. 
The post Hunting down your data with Whitney Merrill: Lock and Code S03E11 appeared first on Malwarebytes Labs.

Depending on where you live, you can ask a company to hand over all the data it has collected about you and, in a matter of weeks as mandated by law, that company has to fork that information over.

Whether the company will abide on time, however, is a different story.

In the European Union, the United Kingdom, and California, consumers have a leg up in understanding what data is collected about them, largely thanks to several laws passed in those regions in the last few years. And at least in California, people can request that a company hand over the data it has collected about them, even if they are not an active user of that company’s product or a customer of that company’s services.

That’s because in today’s world, your data is not collected only by the companies you directly interact with, but also by the companies that your friends and families interact with.

In February of last year, Whitney Merrill proved this was true when she requested her data from the then-popular app Clubhouse. Though Merrill did not have an account with the company and was not a user of the app, she proved that Clubhouse did have her phone number, which had been shared with Clubhouse by Merrill’s contacts who were active users.

Merrill, who has requested her data from several more companies since then, learned more about data privacy compliance than about just what is being collected about her. Each request, Merrill said, can be different from another, and each request is done separately, forcing users who want to learn more about how their data is collected to spend increasingly more of their own time—time which they may not realistically have. The entire model right now, Merrill said, has many flaws.

> “We all interact with thousands and thousands of websites and providers that collect our data—maybe hundreds is probably a better number—in any given week or year. And, as a result, you have to go to each individual one and ask for access to your data… The burden is really on the end user.”
> 
> Whitney Merrill, Data Protection Officer and Privacy Counsel at Asana

This week on the Lock and Code podcast with host David Ruiz, we speak with Merrill about the difficulties of requesting your own data from a company and why some companies seem to interpret data privacy laws as mere suggestions. We also touch on proposed solutions to today’s problems with cross-border data transfers and what “data localization” may lead to in the future.

This video cannot be displayed because your _Functional Cookies_ are currently disabled.

To enable them, please visit our _privacy policy_ and search for the Cookies section. Select _“Click Here”_ to open the Privacy Preference Center and select _“Functional Cookies”_ in the menu. You can switch the tab back to _“Active”_ or disable by moving the tab to _“Inactive.”_ Click _“Save Settings.”_

You can also find us on Apple Podcasts, Spotify, and Google Podcasts, plus whatever preferred podcast platform you use.

_Show notes and credits:_

Intro Music: “Spellbound” by Kevin MacLeod (incompetech.com)  
Licensed under Creative Commons: By Attribution 4.0 License  
http://creativecommons.org/licenses/by/4.0/  
Outro Music: “God God” by Wowa (unminus.com)

Hunting down your data with Whitney Merrill: Lock and Code S03E11

Containers revolutionized the development process, acting as a cornerstone for DevOps initiatives, but containers bring complex security risks that are not always obvious. Organizations that don’t mitigate these risks are vulnerable to attack. 
In this article, we outline how containers contributed to agile development, which unique security risks containers bring into the picture – and what

Containers revolutionized the development process, acting as a cornerstone for DevOps initiatives, but containers bring complex security risks that are not always obvious. Organizations that don't mitigate these risks are vulnerable to attack.

In this article, we outline how containers contributed to agile development, which unique security risks containers bring into the picture – and what organizations can do to secure containerized workloads, going beyond DevOps to achieve _DevSecOps_.

**Why did containers catch on so fast?**

Containers are, in many ways, the evolution of virtualization. The goal was to speed up the development process, creating a more agile route from development through to testing and implementation – a method that's more lightweight than using full-blown virtual machines, anyway.

At the core of this issue is application compatibility, as applications require certain versions of libraries – which could clash with the requirements of other applications. Containers fixed this problem and happened to link up well with development processes and the management infrastructure that drives these processes.

Containers do their job by taking virtualization to the next level. Virtualization abstracts the hardware layer, whereas containers abstract the operating system layer, essentially virtualizing the role of the OS. Containerization works by packaging applications into "containers" that include all the necessary libraries to make an application work, while keeping applications unaware of each other as each app thinks it has the OS to itself.

Functionally, containers are quite simple – a container is just a text file with a description outlining which components should be included in an instance. This simplicity and the more lightweight nature of a container make it easy to use automation (orchestration) tools for deployment throughout the development lifecycle.

**DevOps for the win… but security matters too**

Containers have the power to significantly boost development efficiency – acting as the keys that unlock DevOps. That's likely one of the major reasons why containers have caught on so broadly, with Gartner estimating that by 2023, 70% of organizations will be running containerized workloads.

The process of developing, testing, and deploying apps used to be filled with obstacles, with a constant back and forth between developers and the teams looking after infrastructure. Today, thanks to containers, developers can build and test in an environment that works and simply ship the finished code alongside a spec that defines that environment.

On the operational side teams merely execute this specification to create a matching environment that is ready to use. "Yes, but it works on my machine…" never helped fixed the problem – but today, that's an expression developers no longer need to use because there are no environmental problems to debug.

So, yes, DevOps means rapid development. But there's a missing component: security. This is why we're increasingly hearing about DevSecOps as it evolves from DevOps because developers have noticed that the DevOps model alone does not sufficiently address security concerns.

**Containers introduce several security risks**

Containers simplify the development process but introduce complexity into the security picture. When you tightly pack an entire operating environment into a container only to distribute it widely you also increase the attack surface and open the door to different attack vectors. Any vulnerable libraries packaged with the container will spread these vulnerabilities across countless workloads.

There are several risks. One is a "supply chain attack" where a malevolent actor mounts an attack not by messing with your application, but by modifying one of the packages or components that is supplied with your application. So, teams looking after development efforts need to assess the application they are developing and every library pulled in as a dependency by the container configuration.

The risks to container security also involve the tools that enable containers – from Dockers though to orchestration tools such as Kubernetes, as these tools need to be monitored and protected. You shouldn't, for example, allow sysadmins to run Docker containers as root. Likewise, you need to keep a close guard of your container registries to make sure that these aren't compromised.

**Kernel security at the core of container security**

Some of the container-related security risks are less visible than others. Every container needs access to a kernel – after all, containers are just a type of advanced process isolation. But it is easy to miss the fact that all containers rely on the same kernel – it doesn't matter that the applications inside the containers are segregated from each other.

The kernel that apps in a container see is the same as the kernel that the host relies on to operate. It brings a couple of issues. If the kernel on the host that supports the container is vulnerable to an exploit, this vulnerability may be exploited by starting an attack from an app inside a container.

So fact that the kernel is shared by all the containers on the host means that a flawed kernel must be patched rapidly, or all containers can quickly be affected by the vulnerability.

**Yet again, it comes down to patching**

Keeping the host's kernel up to date is, therefore, an important step in ensuring safe and secure container operations. And it's not just the kernel that needs patching, patches must be applied to the libraries pulled in by a container. But, as we know, consistently patching is easier said than done. That's probably why one study found that 75% of containers analyzed contained a vulnerability that is classified as critical or high risk.

These vulnerabilities can lead to, for example, breakout attacks where an attacker relies on a flawed library within a container to be able to execute code outside of the container. By breaching one container the attacker can eventually reach their intended target whether that's the host system or an application in another container.

In the context of containers maintaining secure libraries can be a real headache – somebody needs to track new vulnerabilities as well as what's been patched and what hasn't. The process is laborious, but it also requires specialist skills which is something your organization would need to acquire if it doesn't have them already.

Given the value of regular, consistent patching those reasons shouldn't be enough to cause the sort of hit-and-miss patching routines that we see, but – particularly when thinking about the OS kernel – the disruption of the required reboots and the associated need to maintain downtime windows can significantly delay patching. Live kernel patching helps mitigate this problem, but it's not yet deployed by all organizations.

**Always include security goals in your container ops**

It's common for cutting-edge tech to introduce new complications when it comes to information security. New tools commonly lead to new and novel exploits. That's true for containers too and while it doesn't undermine the overall value of using containers in your workloads it does mean that you need to keep an eye on the risks posed by containers.

Educating your developers and sysadmins about the common flaws in container security and the best practices that mitigate these flaws is a start. Patching is another important aspect. As always, putting in place the right steps to mitigate cybersecurity flaws will help protect your organization – and allow your team to benefit from that cutting-edge tech without suffering sleepless nights.

Found this article interesting? Follow THN on Facebook, Twitter __ and LinkedIn to read more exclusive content we post.

Yes, Containers Are Terrific, But Watch the Security Risks

Next I.T. is the sixth and largest acquisition to date for Valeo Networks.

ROCKLEDGE, Fla. and MUSKEGON, Mich., May 23, 2022 /PRNewswire/ -- Valeo Networks, a leading Managed Security Service Provider (MSSP), today announced the acquisition of Next I.T., a Michigan-based Managed Service Provider (MSP). Financial terms are not being released.

A recognized and highly respected MSP, Next I.T. is the sixth and largest acquisition to date for Valeo Networks and further supports its goal of building a national network of IT and cybersecurity experts to comprehensively support and protect its client base.

The company will continue to operate as DBA Next I.T. (A Valeo Networks Company), and maintain its current Michigan office locations in Muskegon, Kalamazoo, and Traverse City. The Next I.T. team consists of Microsoft Certified Engineers, Cisco Certified Engineers, and certified technicians in both HP and Dell. They specialize in providing IT solutions for clients across a wide range of industries, including manufacturing, non-profits, and healthcare.

"We are thrilled to welcome Next I.T. to the Valeo Networks family," said Travis Mack, CEO, Valeo Networks. "Their deep skill set and broad expertise will be an excellent fit within our organization, as we continue to advance our nationwide growth strategy. As with each of our divisions, we will partner with Next I.T. to strengthen resources and capabilities in cybersecurity, managed services, cloud solutions, and compliance."

"I am excited for Next I.T. to join Valeo Networks and be part of a larger organization," said Eric Ringelberg, CEO, Next I.T. "With as much as we have grown over the past twenty-one years and having robust IT services in place, this was the natural next step for our continued growth. The Valeo leadership team really stood out to me in offering a true partnership, holding the same values, and having a track record of keeping its acquired companies intact. I look forward to accelerating Next I.T.'s growth throughout the Midwest region with the resources, capital backing, and collaboration that Valeo Networks provides."

**About Next I.T.  
**Next I.T., an award-winning Managed Service Provider (MSP), specializes in industry-specific solutions that leverage technology, increase productivity, and reduce risk for small and medium-sized businesses. It offers a full line of computer hardware, telecommunication equipment, and the professional expertise with remote capabilities to install and service systems. Next I.T. is headquartered in Muskegon, MI, with additional branches in Kalamazoo and Traverse City. For more information, visit www.next-it.net.

**About Valeo Networks  
**Valeo Networks is a full-service, award-winning Managed Security Service Provider (MSSP) that serves State, County, Municipal markets; small-to-medium businesses (SMBs); and non-profit organizations. Firmly seated in the top 5% of revenue generating MSSPs nationwide—making it one of the largest MSSPs nationally—Valeo Networks provides solutions in the areas of cybersecurity, compliance, cloud, network infrastructure, and managed IT services. With over 20 years of industry experience, Valeo Networks is headquartered in Rockledge, FL, with additional locations nationwide. Learn more at www.valeonetworks.com.

Tag

#mac