Two US Senators claim that the CIA has been running an unregulated — and almost certainly illegal — mass surveillance program on Americans.
The senator’s statement. Some declassified information from the CIA.
No real details yet.
Endpoint detection and response (EDR) can only take you so far in identifying Log4j exploit attempts. Here’s why dynamic checks are needed to uncover vulnerable versions of Log4j.
When the Log4j vulnerability was disclosed at the tail end of 2021, it caused many IT teams to put down their well earned eggnog and cast a concerned look at their environment. Unfortunately, understanding what was vulnerable to this newly disclosed flaw was far more difficult than simply pulling an accurate inventory of Log4j instances, with the troublesome library often harder to track down than a Playstation 5.
Using an endpoint agent, for example endpoint detection and response (EDR), or a credentialed scan to identify Log4j instances will only get you so far. Like many Java libraries, Log4j is often bundled into “Fat Jars” (Jar files that include all external dependencies) or inserted directly into the source code as a way of shading the library versions to lessen the probability of conflicts. Simply asking “Do you have Log4j installed?” isn’t going to give you a very clear understanding of where you’re vulnerable.
But “EDR will block attempts to exploit Log4j!” I hear you all cry out in delight. Not so fast. An attacker could easily stay within the Java Virtual Machine (JVM), away from the prying eyes of the EDR process monitors; blocking outbound calls from a server is going to end badly. The idea of hiding nefarious activity within the Java virtual machine isn’t new, but all the top EDR vendors have been slow to address this rather large chink in their armor. EDR can stop breaches (as long as they’re not Java based).
In order to deal with the Log4j detection issue, Tenable released a whole new approach to assessment within hours of the legendary flaw being announced. Put simply, our dynamic checks fired a Java Naming and Directory Interface (JNDI) query into targets that instructed any systems vulnerable to Log4j to send a unique token to a Tenable hosted system that the scanner could look up to see if a message had been received. This approach ensured we’d be able to more easily uncover vulnerable versions of Log4j across a multitude of ports and protocols, because the only tokens being sent would be from those systems that had the flawed library somewhere within the stack or application code.
And we saw a lot of those unique tokens being sent to Tenable. Days after disclosure, we were seeing over 1,400 new tokens … EVERY SECOND and one in 10 assets assessed by Tenable were vulnerable.
In the case of Log4j, a false negative could mean a system is left vulnerable due to a poor assessment. Relying on endpoint detection to block exploitation is nowhere near enough of a defense, leading to a surefire foothold for any enterprising attacker. Tenable is investing significant effort in ensuring we continue to lead the market in detecting Log4Shell across the ever growing list of applications and protocols that are vulnerable.
Read the technical whitepaper for more information on the new approach to identifying Log4j via the dynamic plugins
VIsit our landing page to keep up to date with all the log4j news
Read the blog, Assess Log4Shell Like an Attacker with Tenable’s Dynamic Detections
Reported scams surged by 17% in the final quarter of 2021 in the UK, while attempted scams increased by 70% over the same period
Aiming at enterprises that are managing increasingly complex IT infrastructure, F5 is releasing a new SaaS-based security, multicloud networking, and edge computing platform, F5 Distributed Cloud Services, as an expansion to its application delivery and security product portfolio.
As part of the announcement, made at its annual Agility conference Tuesday, the company also unveiled the first new service on the platform, F5 Distributed Cloud WAAP (Web application and API protection), which integrates the existing security capabilities from across F5 applications into a unified SaaS (software-as-a-service) based offering.
This blog was written by an independent guest blogger.
Microservices architecture is a convenient way to silo different software services compared to traditional software architecture and design. However, with multiple microservices communicating amongst each other – the attack surface of the network is greatly increased.
The security of such a system depends on the security of all the services. Any deviation in the system’s security ultimately undermines the integrity of the entire network. The number of vulnerabilities in a network based on microservices architecture can quickly grow from several to thousands of individual links depending on the number of services and how they communicate together.
This article will examine edge security in the context of microservices deployments and how APIs and API gateways set up at the edge can be used to secure service-to-service communications in a zero-trust environment.
There is no single definition for what qualifies as a microservice. However, over time developers and industry standards have accepted a few key ideas. Microservices function similarly to how WordPress plugins provide a variety of siloed services on a website.
First, services in a microservice architecture typically communicate amongst one another on a network using protocols like HTTP. One advantage to utilizing a microservices architecture is that it greatly enhances the speed of your entire network. These services are then organized based on their function and developed independently of one another (and are also independently deployable).
Ensuring that your microservices architecture is secure is essential. Hackers can use phishing scams to steal credentials and break into your network. So, if you build a network that has only a single point of security, you may find that a single breach can give hackers access to any number of services within your entire network.
Outdated software can easily lead to network vulnerabilities. By establishing a system to secure each microservice you can prevent hackers from spreading their reach if they manage to crack into a single service.
A zero-trust environment in a cybersecurity context means the elimination of trust between individual parts of a digital system, which would otherwise expose those parts to security vulnerabilities. Although some connections are obvious, cybersecurity consultation can help you assess how vulnerable your network is.
Essentially, by siloing a network’s set of services and then eliminating their ability to trust one another we can increase security. If you find that you are unable to remove trust in your microservices architecture, the least you can do is minimize trust between services. Often businesses that have had their internal security breached, have had to seek reputation management services to protect their brand.
Another way to think of it is like this: your network represents a house that is full of rooms and each room is a service. Eliminating trust means locking all the doors to each room and then requiring a key every time a user wants to open that door.
How do we go about creating this security? Typically, when a microservices architecture is used, HTTP or gRPC are used to communicate in real-time. Apache Kafka and RabbitMQ are also examples of other communication protocols for applications. In order to secure these messages, we need to make sure that requests from a client application not only pass through security at the edge, but also internally.
One way to make sure that access between services is secure is to implement authentication between services using Mutual Transport Layer Security (mTLS). However, in order to increase security, requests must be validated at the edge of the microservice and not just the edge of the network.
Each microservice then validates the certificate of the calling microservice and determines whether the certificate itself and the certificate’s issuer are trusted. Once the microservice has identified the caller, the microservice performs an authorization based only on the authentication credentials provided. This will check whether the caller is even able to do what it is requesting.
One way to enhance open source security and increase authentication and authorization speed is to utilize a proxy component that is deployed alongside the microservices. The proxy then intercepts all the calls that are placed to and from the microservice and prevents them from accessing the microservice directly.
The next step is to ensure that user context is passed securely between microservices. It’s important to ensure your network is secure, but also to ensure that communications intra-network are also secure.
The most common way this system works is by placing an API gateway at the edge of the microservices architecture deployment. The API gateway checks and validates user context corresponding to the application that made the call. Typically, the calling application can run the API just by itself, or for another user.
In either case, the API gateway acts like a sluice to regulate the flow of user context calls. When carrying these calls, the best way to cryptographically carry them is by using a JSON Web Token (JWT).
At the edge of the microservice, the JWT will be validated to make sure that it comes from a trusted issuer. Then, when one microservice communicates to another, the calling microservice can either feed the validated JWT to the new service or exchange it for a new JWT by communicating with another security token service that the recipient microservice trusts.
This way, one microservice could have an independent security token service separate from another verification service. This double-redundancy further strengthens the security of your services.
Once the end-microservice has verified the JWT, it can authorize the calling user based on the credentials that the JWT carries. Like with authentication and authorization, a proxy component intercepts these requests that come in and out of the microservice.
Your entire network is only as secure as its weakest link. Every day businesses leave their data unprotected and vulnerable to hackers. Securing your microservices through multiple layers of security is one way to minimize these attack vectors. However, even if you take all of these steps it’s still important to consider threat detection and monitoring services.
Upgrade the security of your microservices architecture and consider where your vulnerabilities are in order to prevent unauthorized access to one microservice bleeding through to your other services. When you develop microservices as silos remember to utilize proxies and silo the security of the services by using JWT and mTLS. Your end goal should be to minimize trust, or if possible, establish a zero-trust environment.
CrowdStrike report warns that threat actors are getting smarter at evasion
While acknowledging there are “not currently any specific credible threats to the U.S.,” Anne Neuberger, deputy national security advisor for cyber, continued how “we’ve been working with the private sector, engaging, sharing specific information, requesting that they act to reduce the cybersecurity risk of their organization, and providing very focused advice on how to do so.”
Neuberger was briefing the global media when she made this observation on February 2 as she spoke to the continued presence of Russian cyber threats to Ukraine and beyond. In her briefing, Neuberger, was unambiguous: “We’ve been warning for weeks and months, both publicly and privately, that cyberattacks could be part of a broad-based Russian effort to destabilize and further invade Ukraine. The Russians have used cyber as a key component of their force projection over the last decade, including previously in Ukraine, in the 2015 timeframe.”
Government tries to reassure country amidst Russian disinformation effort
In January, KrebsOnSecurity examined clues left behind by “Wazawaka,” the hacker handle chosen by a major ransomware criminal in the Russian-speaking cybercrime scene. Wazawaka has since “lost his mind” according to his erstwhile colleagues, creating a Twitter account to drop exploit code for a widely-used virtual private networking (VPN) appliance, and publishing bizarre selfie videos taunting security researchers and journalists.
Wazawaka, a.k.a. Mikhail P. Matveev, a.k.a. “Orange,” a.k.a. “Boriselcin,” showing off his missing ring finger.
In last month’s story, we explored clues that led from Wazawaka’s multitude of monikers, email addresses, and passwords to a 30-something father in Abakan, Russia named Mikhail Pavlovich Matveev. This post concerns itself with the other half of Wazawaka’s identities not mentioned in the first story, such as how Wazawaka also ran the Babuk ransomware affiliate program, and later became “Orange,” the founder of the ransomware-focused Dark Web forum known as “RAMP.”
The same day the initial profile on Wazawaka was published here, someone registered the Twitter account “@fuck_maze,” a possible reference to the now-defunct Maze Ransomware gang.
The background photo for the @fuck_maze profile included a logo that read “Waka Waka;” the bio for the account took a swipe at Dmitry Smilyanets, a researcher and blogger for The Record who was once part of a cybercrime group the Justice Department called the “largest known data breach conspiracy ever prosecuted.”
The @fuck_maze account messaged me a few times on Twitter, but largely stayed silent until Jan. 25, when it tweeted three videos of a man who appeared identical to Matveev’s social media profile on Vkontakte (the Russian version of Facebook). The man seemed to be slurring his words quite a bit, and started by hurling obscenities at Smilyanets, journalist Catalin Cimpanu (also at The Record), and a security researcher from Cisco Talos.
At the beginning of the videos, Matveev holds up his left hand to demonstrate that his ring finger is missing. This he smugly presents as evidence that he is indeed Wazawaka.
The story goes that Wazwaka at one point made a bet wherein he wagered his finger, and upon losing the bet severed it himself. It’s unclear if that is the real story about how Wazawaka lost the ring finger on his left hand; his remaining fingers appear oddly crooked.
“Hello Brian Krebs! You did a really great job actually, really well, fucking great — it’s great that journalism works so well in the US,” Matveev said in the video. “By the way, it is my voice in the background, I just love myself a lot.”
In one of his three videos, Wazawaka says he’s going to release exploit code for a security vulnerability. Later that same day, the @fuck_maze account posted a link to a Pastebin-like site that included working exploit code for a recently patched security hole in SonicWall VPN appliances (CVE-2021-20028).
When KrebsOnSecurity first started researching Wazawaka in 2021, it appeared this individual also used two other important nicknames on the Russian-speaking crime forums. One was Boriselcin, a particularly talkative and brash personality who was simultaneously the public persona of Babuk, a ransomware affiliate program that surfaced on New Year’s Eve 2020.
The other handle that appeared tied to Wazawaka was “Orange,” the founder of the RAMP ransomware forum. I just couldn’t convincingly connect those two identities with Wazawaka using the information available at the time. This post is an attempt to remedy that.
On Aug. 26, 2020, a new user named Biba99 registered on the English language cybercrime forum RaidForums. But the Biba99 account didn’t post to RaidForums until Dec. 31, 2020, when they announced the creation of the Babuk ransomware affiliate program.
On January 1, 2021, a new user “Babuk” registered on the crime forum Verified, using the email address teresacox19963@gmail.com, and the instant message address “admin@babuk.im.” “We run an affiliate program,” Babuk explained in their introductory post on Verified.
A variety of clues suggest Boriselcin was the individual acting as spokesperson for Babuk. Boriselcin talked openly on the forums about working with Babuk, and fought with other members of the ransomware gang about publishing access to data stolen from victim organizations.
According to analysts at cyber intelligence firm Flashpoint, between January and the end of March 2021, Babuk continued to post databases stolen from companies that refused to pay a ransom, but they posted the leaks to both their victim shaming blog and to multiple cybercrime forums, an unusual approach.
This matches the ethos and activity of Wazawaka’s posts on the crime forums over the past two years. As I wrote in January:
“Wazawaka seems to have adopted the uniquely communitarian view that when organizations being held for ransom decline to cooperate or pay up, any data stolen from the victim should be published on the Russian cybercrime forums for all to plunder — not privately sold to the highest bidder. In thread after thread on the crime forum XSS, Wazawaka’s alias ‘Uhodiransomwar’ can be seen posting download links to databases from companies that have refused to negotiate after five days.”
Around Apr. 27, 2021, Babuk hacked the Washington Metropolitan Police Department, demanding $4 million in virtual currency in exchange for a promise not to publish the police department’s internal data.
Flashpoint says that on April 30, Babuk announced they were shuttering the affiliate program and its encryption services, and that they would now focus on data theft and extortion instead. On May 3, the group posted two additional victims of their data theft enterprise, showing they are still in operation.
On May 11, 2021, Babuk declared negotiations with the MPD had reached an impasse, and leaked 250 gigabytes worth of MPD data.
On May 14, 2021, Boriselcin announced on XSS his intention to post a writeup on how they hacked the DC Police (Boriselcin claims it was via the organization’s VPN).
On May 17, Babuk posted about an upcoming new ransomware leaks site that will serve as a “huge platform for independent leaks,” — i.e., a community that would publish data stolen by no-name ransomware groups that don’t already have their own leaks/victim shaming platforms.
On May 31, 2021, Babuk’s website began redirecting to Payload[.]bin. On June 23, 2021, Biba99 posted to RaidForums saying he’s willing to buy zero-day vulnerabilities in corporate VPN products. Biba99 posts his unique user ID for Tox, a peer-to-peer instant messaging service.
On July 13, 2021, Payload[.]bin was renamed to RAMP, which according to Orange stands for “Ransom Anon Market Place.” Flashpoint says RAMP was created “directly in response to several large Dark Web forums banning ransomware collectives on their site following the Colonial Pipeline attack by ransomware group ‘DarkSide.” [links added]
“Babuk noted that this new platform will not have rules or ‘bosses,’” Flashpoint observed in a report on the group. “This reaction distinguishes Babuk from other ransomware collectives, many of which changed their rules following the attack to attract less attention from law enforcement.”
The RAMP forum opening was announced by the user “TetyaSluha. That nickname soon switched to “Orange,” who appears to have registered on RAMP with the email address “teresacox19963@gmail.com.” Recall that this is the same email address used by the spokesperson for the Babuk ransomware gang — Boriselcin/Biba99.
In a post on RAMP Aug. 18, 2021, in which Orange is attempting to recruit penetration testers, he claimed the same Tox ID that Biba99 used on RaidForums.
On Aug. 22, Orange announced a new ransomware affiliate program called “Groove,” which claimed to be an aggressive, financially motivated criminal organization dealing in industrial espionage for the previous two years.
In November 2021, Groove’s blog disappeared, and Boriselcin posted a long article to the XSS crime forum explaining that Groove was little more than a pet project to mess with the media and security industries.
On Sept. 13, 2021, Boriselcin posted to XSS saying he would pay handsomely for a reliable, working exploit for CVE-2021-20028, the same exploit that @fuck_maze would later release to Twitter on Jan. 25, 2022.
Asked for comment on this research, cyber intelligence firm Intel 471 confirmed that its analysts reached the same conclusion.
“We identified the user as the Russian national Михаил Павлович Матвеев aka Mikhail Pavlovich Matveev, who was widely known in the underground community as the actor using the Wazawaka handle, a.k.a. Alfredpetr, andry1976, arestedByFbi, boriselcin, donaldo, ebanatv2, futurama, gotowork, m0sad, m1x, Ment0s, ment0s, Ment0s, Mixalen, mrbotnet, Orange, posholnarabotu, popalvprosak, TetyaSluha, uhodiransomwar, and 999,” Intel 471 wrote.
As usual, I put together a rough mind map on how all these data points indicate a connection between Wazawaka, Orange, and Boriselcin.
A mind map connecting Wazawaka to the RAMP forum administrator “Orange” and the founder of the Babuk ransomware gang.
As noted in January’s profile, Wazawaka has worked with at least two different ransomware affiliate programs, including LockBit. Wazawaka said LockBit had paid him roughly $500,000 in commissions for the six months leading up to September 2020.
Wazawaka also said he’d teamed up with DarkSide, the ransomware affiliate group responsible for the six-day outage at Colonial Pipeline last year that caused nationwide fuel shortages and price spikes. The U.S. Department of State has since offered a $5 million reward for information leading to the arrest and conviction of any DarkSide affiliates.
