Category: OpenDns

BlackCat Ransomware, ZingoStealer & BumbleBee Loader

This month, the Cisco Umbrella team – in conjunction with Talos – has witnessed the rise of complex cyberattacks. In today’s edition of the Cybersecurity Threat Spotlight, we unpack the tactics, techniques, and procedures used in these attacks.

Want to see how Cisco Umbrella can protect your network? Sign up for a free trial today!

BlackCat Ransomware

Threat Type: Ransomware

Attack Chain:

Graphic that shows the attack chain for BlackCat Ransomware. The attack chain is as follows: Initial Access to Defense Evasion to Persistence with Reverse SSH to Credential access to Lateral Movement to Command and Control to Data Exfiltration to BlackCat Ransomware. The graphic indicates that Cisco Secure protects users from Initial Access and Persistence With Reverse SSH.

Description: BlackCat – also known as “ALPHV”- is a ransomware which uses ransomware-as-a-service model and double ransom schema (encrypted files and stolen file disclosure). It first appeared in November 2021 and, since then, targeted companies have been hit across the globe.

BlackCat Spotlight: BlackCat ransomware has quickly gained notoriety for being used in double ransom (encrypted files and stolen file disclosure) attacks against companies. While it targets companies across the globe, more than 30% of the compromises happened to companies based in the U.S.

There is a connection between the BlackCat, BlackMatter and DarkSide ransomware groups, recently confirmed by the BlackCat representative. Attack kill chain follows the blueprint of other human-operated ransomware attacks: initial compromise, followed by an exploration and data exfiltration phase, then attack preparation and finally, the ransomware execution. The key aspect of such attacks is that adversaries take time exploring the environment and preparing it for a successful and broad attack before launching the ransomware. Some of the attacks took up to two weeks from the initial to final stage, so it is key to have capabilities to detect such activities to counter them.

Target Geolocations: U.S., Canada, EU, China, India, Philippines, Australia
Target Data: Sensitive Information, Browser Information
Target Businesses: Any
Exploits: N/A

Mitre ATT&CK for BlackCat

Initial Access:
Valid Accounts: Local Accounts

Discovery:
Account Discovery
System Information Discovery
Network Service Discovery
File and Directory Discovery
Security Software Discovery
ADrecon
Sofperfect Network Scanner

Persistence:
Scheduled Task
Image File Execution Options Injection
Reverse SSH Tunnel

Evasion:
Disable System Logs
Disable Endpoint Protection
Gmer

Credential Access:
OS Credential Dumping: LSASS Memory
Credentials from Password Stores: Credentials from Web Browsers

Command and Control:
Reverse SSH Tunnel
Impacket

Lateral Movement:
Lateral Tool Transfer
Impacket
Remote Services: SSH, RDP, Poershell, Psexec

Impact:
Group Policy
Netlogon Share
Data Encrypted for Impact
Inhibit System Recovery

IOCs

Domains:
windows[.]menu

IPs:
52.149.228[.]45
20.46.245[.]56

Additional Information:
From BlackMatter to BlackCat: Analyzing two attacks from one affiliate

Which Cisco Products Can Block:
Cisco Secure Endpoint
Cisco Secure Firewall/Secure IPS
Cisco Secure Malware Analytics
Cisco Umbrella

ZingoStealer

Threat Type: Information Stealer

Attack Chain:

Graphic that shows the attack chain of ZingoStealer, which is as follows: Trojanized Application Download to ZingoStealer Malware to Data Exfiltration to Command and Control to Additional Payloads. The graphic indicates that Cisco Secure products protect users from Trojanized Application Download, ZingoStealer Malware, Data Exfiltration and Command and Control.

Description: ZingoStealer is an information stealer released by a threat actor known as “Haskers Gang.” The malware leverages Telegram chat features to facilitate malware executable build delivery and data exfiltration. The malware can exfiltrate sensitive information like credentials, steal cryptocurrency wallet information, and mine cryptocurrency on victims’ systems. ZingoStealer has the ability to download additional malware such as RedLine Stealer and the XMRig cryptocurrency mining malware.

ZingoStealer Spotlight: Cisco Talos recently observed a new information stealer, called “ZingoStealer” that has been released for free by a threat actor known as “Haskers Gang.” This information stealer, first introduced to the wild in March 2022, is currently undergoing active development and multiple releases of new versions have been observed recently. In many cases, ZingoStealer is being distributed under the guise of game cheats, cracks and code generators.

The stealer is an obfuscated .NET executable which downloads files providing core functionality an attacker-controlled server. The malware can exfiltrate sensitive information like credentials, steal cryptocurrency wallet information, and mine cryptocurrency on victims’ systems. The malware is also used as a loader for other malware payloads, such as RedLine Stealer and the XMRig cryptocurrency mining malware.

Target Geolocations: CIS
Target Data: User Credentials, Browser Data, Financial and Personal Information, Cryptocurrency Wallets, Data From Browser Extensions
Target Businesses: Any
Exploits: N/A

Mitre ATT&CK for ZingoStealer

Initial Access:
Trojanized Applications

Credential Access:
Credentials from Password Stores
Steal Web Session Cookie
Unsecured Credentials
Credentials from Password Stores: Credentials from Web Browsers

Discovery:
Account Discovery
Software Discovery
Process Discovery
System Time Discovery
System Service Discovery
System Location Discovery

Persistence:
Registry Run Keys/Startup Folder
Scheduled Task/Job: Scheduled Task

Privilege Escalation:
N/A

Execution:
User Execution
Command and Scripting Interpreter: PowerShell

Evasion:
Obfuscated Files or Information

Collection:
Archive Collected Data: Archive via Utility
Data Staged: Local Data Staging

Command and Control:
Application Layer Protocol: Web Protocols

Exfiltration:
Exfiltration Over C2 Channel

IOCs

Domains:
nominally[.]ru

Additional Information:
Threat Spotlight: “Haskers Gang” Introduces New ZingoStealer

Which Cisco Products Can Block:
Cisco Secure Endpoint
Cisco Secure Email
Cisco Secure Firewall/Secure IPS
Cisco Secure Malware Analytics
Cisco Umbrella
Cisco Secure Web Appliance

BumbleBee Loader

Threat Type: Loader

Attack Chain:

A graphic showing the attack chain of BumbleBee Loader, which is as follows: Malspam to Malicious URL or HTML Attachment to Download Malicious ISO File to Fingerprinting to BumbleBee Loader to Command and Control to CobaltStrike. The graphic indicates that Cisco Secure products protect users from malspam, malicious URL or HTML attachment, command and control, and Cobalt Strike.

Description: BumbleBee is a loader that has anti-virtualization checks and loader capabilities. The goal of the malware is to take a foothold in the compromised system to download and execute additional payloads. BumbleBee was observed to load Cobalt Strike, shellcode, Sliver and Meterpreter malware.

BumbleBee Spotlight: Security researchers noticed the appearance of the new malware being used by Initial Access Brokers, which previously relied on  BazaLoader and IcedID malware. Dubbed BumbleBee due to presence of unique User-Agent “bumblebee” in early campaigns, this malware appears to be in active development.

It already employs complex anti-virtualization techniques, as well as uses asynchronous procedure call (APC) injection to launch the shellcode and LOLBins to avoid detections. Delivery chain relies on user interaction to follow the links and open malicious ISO or IMG file. Loader achieves persistence via scheduled task which launches Visual Basic Script to load BumbleBee DLL. Afterwards, the execution malware communicates with the Command-and-Control server and downloads additional payloads such as Cobalt Strike, shellcode, Sliver and Meterpreter. Threat actors using such payloads have been linked to ransomware campaigns.

Target Geolocations: Canada, U.S., Japan
Target Data: N/A
Target Businesses: Any
Exploits: N/A

Mitre ATT&CK for BumbleBee

Initial Access:
Malspam

Persistence:
Scheduled Task/Job

Execution:
Scheduled Task/Job: Scheduled Task
Command and Scripting Interpreter: Virtual Basic
User Execution: Malicious File

Evasion:
System Binary Proxy Execution: Rundll32
Virtualization/Sandbox Evasion: System Checks
Process Injection: Asynchronous Procedure Call

Discovery:
System Information Discovery
System Network Configuration Discovery
System Network Connections Discovery

Collection:
N/A

Command and Control:
Application Layer Protocol

Exfiltration:
N/A

IOCs

Domains:
hxxps://www.transferxl[.]com/download/00zs2K2Njx25cf         hxxps://www.transferxl[.]com/download/00mP423PZy3Qb
hxxps://www.transferxl[.]com/download/00jmM0qhpgWydN  hxxps://www.transferxl[.]com/download/00jGC0dqWkf3hZ
hxxps://www.transferxl[.]com/download/00D6JXf66HJQV
hxxps://www.transferxl[.]com/download/006wWqw66ZHbP
hxxps://storage.googleapis[.]com/vke8rq4dfj4fej.appspot.com/sh/f/pub/m/0/fg6V6Rqf7gJNG.html

CS Domains:
hojimizeg[.]com
notixow[.]com
rewujisaf[.]com

IPs:
23.82.19[.]208
192.236.198[.]63
45.147.229[.]177

Additional Information:
This isn’t Optimus Prime’s Bumblebee but it’s Still Transforming
Orion Threat Alert: Flight of the BumbleBee

Which Cisco Products Can Block:
Cisco Secure Endpoint
Cisco Secure Email
Cisco Secure Firewall/Secure IPS
Cisco Secure Malware Analytics
Cisco Umbrella
Cisco Secure Web Appliance

Source :
https://umbrella.cisco.com/blog/cybersecurity-threat-spotlight-blackcat-ransomware-zingostealer-bumblebee-loader

Cisco Umbrella Named a 2022 SC Awards Finalist for Best SME Security Solution

SC Awards from SC Media are known for honoring the best people, products and companies in cybersecurity. One of the industry’s most respected media outlets, SC Media enlists a select pool of experts from the information security community to review more than 800 entries in 35+ categories.

Last year Cisco Umbrella took home SC’s top award for Best SME Security Solution, and we are thrilled to be a finalist again this year – with the winner to be announced in August.

Small and mid-size enterprises need an effective, easy-to-deploy security solution

We firmly believe small and medium-sized businesses deserve big protection. The chilling statistic that 60% of small- and medium-sized businesses go out of business within six months of a cyberattack1 underscores the need for an effective and easy to implement security solution for companies that are likely to have little or no dedicated IT staff.

Blocking threats before they reach the network, endpoints, and end users, Umbrella enables even small IT teams to monitor and respond to threats effectively – like it does for Cape Air.

Cape Air uses Cisco Umbrella to simplify operations and improve security

Headquartered in Hyannis, Massachusetts, Cape Air is a regional airline that provides service to some of the world’s most beautiful destinations.  But when frequent malware infections disrupt core services and the customer experience, the brand reputation suffers. For Cape Air, service delays due to malware infections became a common challenge.

Brett Stone, Cape Air’s network operations manager needed to stop threats before they caused service outages. He recognized that Cisco Umbrella could help Cape Air reduce infections since it blocks malware, phishing, command-and-control requests, and other threats at the DNS layer before a connection is even established.

He configured Umbrella within 30 minutes — and saw immediate results:

“From the moment we deployed Umbrella, it was like night and day in the number of tickets we had open because of infections and PCs that kept getting compromised in the past. We were amazed because the next day we didn’t have to fix these problems anymore. Then we could do all those other things that were important to us; we finally had time for them.” – Brett Stone

Stone recalls how malware remediation used to consume all of Cape Air’s network technicians’ time. “Before Umbrella, I had three technicians working 40 hours a week, and all they did for a year was fix malware infections and reimage computers,” Stone recalls. “Thankfully, those days are gone. Now we have zero, or rarely one, malware infection. I don’t remember the last time something got through Cisco Umbrella within the last year or two.”

Want to learn more about how Cisco Umbrella serves small-to-midsize businesses?

Threats are never going to stop coming. But with simple deployment and powerful protection, visibility, and performance, Cisco Umbrella can provide the big protection you need.

Check out our ebook Big Threats to Small Business to learn more about how we meet the unique cybersecurity needs of small and medium sized businesses. And if you’re ready to see our solution in action, check out a free Cisco Umbrella Live Demo.

Source :
https://umbrella.cisco.com/blog/cisco-umbrella-named-2022-sc-awards-finalist-best-sme-security-solution

Cloudflare’s approach to handling BMC vulnerabilities

In recent years, management interfaces on servers like a Baseboard Management Controller (BMC) have been the target of cyber attacks including ransomware, implants, and disruptive operations. Common BMC vulnerabilities like Pantsdown and USBAnywhere, combined with infrequent firmware updates, have left servers vulnerable.

We were recently informed from a trusted vendor of new, critical vulnerabilities in popular BMC software that we use in our fleet. Below is a summary of what was discovered, how we mitigated the impact, and how we look to prevent these types of vulnerabilities from having an impact on Cloudflare and our customers.

Background

A baseboard management controller is a small, specialized processor used for remote monitoring and management of a host system. This processor has multiple connections to the host system, giving it the ability to monitor hardware, update BIOS firmware, power cycle the host, and many more things.

Access to the BMC can be local or, in some cases, remote. With remote vectors open, there is potential for malware to be installed on the BMC from the local host via PCI Express or the Low Pin Count (LPC) interface. With compromised software on the BMC, malware or spyware could maintain persistence on the server.

According to the National Vulnerability Database, the two BMC chips (ASPEED AST2400 and AST2500) have implemented Advanced High-Performance Bus (AHB) bridges, which allow arbitrary read and write access to the physical address space of the BMC from the host. This means that malware running on the server can also access the RAM of the BMC.

These BMC vulnerabilities are sufficient to enable ransomware propagation, server bricking, and data theft.

Impacted versions

Numerous vulnerabilities were found to affect the QuantaGrid D52B cloud server due to vulnerable software found in the BMC. These vulnerabilities are associated with specific interfaces that are exposed on AST2400 and AST2500 and explained in CVE-2019-6260. The vulnerable interfaces in question are:

  • iLPC2AHB bridge Pt I
  • iLPC2AHB bridge Pt II
  • PCIe VGA P2A bridge
  • DMA from/to arbitrary BMC memory via X-DMA
  • UART-based SoC Debug interface
  • LPC2AHB bridge
  • PCIe BMC P2A bridge
  • Watchdog setup

An attacker might be able to update the BMC directly using SoCFlash through inband LPC or BMC debug universal async receiver-transmitter (UART) serial console. While this might be thought of as a usual path in case of total corruption, this is actually an abuse within SoCFlash by using any open interface for flashing.

Mitigations and response

Updated firmware

We reached out to one of our manufacturers, Quanta, to validate that existing firmware within a subset of systems was in fact patched against these vulnerabilities. While some versions of our firmware were not vulnerable, others were. A patch was released, tested, and deployed on the affected BMCs within our fleet.

Cloudflare Security and Infrastructure teams also proactively worked with additional manufacturers to validate their own BMC patches were not explicitly vulnerable to these firmware vulnerabilities and interfaces.

Reduced exposure of BMC remote interfaces

It is a standard practice within our data centers to implement network segmentation to separate different planes of traffic. Our out-of-band networks are not exposed to the outside world and only accessible within their respective data centers. Access to any management network goes through a defense in depth approach, restricting connectivity to jumphosts and authentication/authorization through our zero trust Cloudflare One service.

Reduced exposure of BMC local interfaces

Applications within a host are limited in what can call out to the BMC. This is done to restrict what can be done from the host to the BMC and allow for secure in-band updating and userspace logging and monitoring.

Do not use default passwords

This sounds like common knowledge for most companies, but we still follow a standard process of changing not just the default username and passwords that come with BMC software, but disabling the default accounts to prevent them from ever being used. Any static accounts follow a regular password rotation.

BMC logging and auditing

We log all activity by default on our BMCs. Logs that are captured include the following:

  • Authentication (Successful, Unsuccessful)
  • Authorization (user/service)
  • Interfaces (SOL, CLI, UI)
  • System status (Power on/off, reboots)
  • System changes (firmware updates, flashing methods)

We were able to validate that there was no malicious activity detected.

What’s next for the BMC

Cloudflare regularly works with several original design manufacturers (ODMs) to produce the highest performing, efficient, and secure computing systems according to our own specifications. The standard processors used for our baseboard management controller often ship with proprietary firmware which is less transparent and more cumbersome to maintain for us and our ODMs. We believe in improving on every component of the systems we operate in over 270 cities around the world.

OpenBMC

We are moving forward with OpenBMC, an open-source firmware for our supported baseboard management controllers. Based on the Yocto Project, a toolchain for Linux on embedded systems, OpenBMC will enable us to specify, build, and configure our own firmware based on the latest Linux kernel featureset per our specification, similar to the physical hardware and ODMs.

OpenBMC firmware will enable:

  • Latest stable and patched Linux kernel
  • Internally-managed TLS certificates for secure, trusted communication across our isolated management network
  • Fine-grained credentials management
  • Faster response time for patching and critical updates

While many of these features are community-driven, vulnerabilities like Pantsdown are patched quickly.

Extending secure boot

You may have read about our recent work securing the boot process with a hardware root-of-trust, but the BMC has its own boot process that often starts as soon as the system gets power. Newer versions of the BMC chips we use, as well as leveraging cutting edge security co-processors, will allow us to extend our secure boot capabilities prior to loading our UEFI firmware by validating cryptographic signatures on our BMC/OpenBMC firmware. By extending our security boot chain to the very first device that has power to our systems, we greatly reduce the impact of malicious implants that can be used to take down a server.

Conclusion

While this vulnerability ended up being one we could quickly resolve through firmware updates with Quanta and quick action by our teams to validate and patch our fleet, we are continuing to innovate through OpenBMC, and secure root of trust to ensure that our fleet is as secure as possible. We are grateful to our partners for their quick action and are always glad to report any risks and our mitigations to ensure that you can trust how seriously we take your security.

Source :
https://blog.cloudflare.com/bmc-vuln/

How we improved DNS record build speed by more than 4,000x

Since my previous blog about Secondary DNS, Cloudflare’s DNS traffic has more than doubled from 15.8 trillion DNS queries per month to 38.7 trillion. Our network now spans over 270 cities in over 100 countries, interconnecting with more than 10,000 networks globally. According to w3 stats, “Cloudflare is used as a DNS server provider by 15.3% of all the websites.” This means we have an enormous responsibility to serve DNS in the fastest and most reliable way possible.

Although the response time we have on DNS queries is the most important performance metric, there is another metric that sometimes goes unnoticed. DNS Record Propagation time is how long it takes changes submitted to our API to be reflected in our DNS query responses. Every millisecond counts here as it allows customers to quickly change configuration, making their systems much more agile. Although our DNS propagation pipeline was already known to be very fast, we had identified several improvements that, if implemented, would massively improve performance. In this blog post I’ll explain how we managed to drastically improve our DNS record propagation speed, and the impact it has on our customers.

How DNS records are propagated

Cloudflare uses a multi-stage pipeline that takes our customers’ DNS record changes and pushes them to our global network, so they are available all over the world.

The steps shown in the diagram above are:

  1. Customer makes a change to a record via our DNS Records API (or UI).
  2. The change is persisted to the database.
  3. The database event triggers a Kafka message which is consumed by the Zone Builder.
  4. The Zone Builder takes the message, collects the contents of the zone from the database and pushes it to Quicksilver, our distributed KV store.
  5. Quicksilver then propagates this information to the network.

Of course, this is a simplified version of what is happening. In reality, our API receives thousands of requests per second. All POST/PUT/PATCH/DELETE requests ultimately result in a DNS record change. Each of these changes needs to be actioned so that the information we show through our API and in the Cloudflare dashboard is eventually consistent with the information we use to respond to DNS queries.

Historically, one of the largest bottlenecks in the DNS propagation pipeline was the Zone Builder, shown in step 4 above. Responsible for collecting and organizing records to be written to our global network, our Zone Builder often ate up most of the propagation time, especially for larger zones. As we continue to scale, it is important for us to remove any bottlenecks that may exist in our systems, and this was clearly identified as one such bottleneck.

Growing pains

When the pipeline shown above was first announced, the Zone Builder received somewhere between 5 and 10 DNS record changes per second. Although the Zone Builder at the time was a massive improvement on the previous system, it was not going to last long given the growth that Cloudflare was and still is experiencing. Fast-forward to today, we receive on average 250 DNS record changes per second, a staggering 25x growth from when the Zone Builder was first announced.

The way that the Zone Builder was initially designed was quite simple. When a zone changed, the Zone Builder would grab all the records from the database for that zone and compare them with the records stored in Quicksilver. Any differences were fixed to maintain consistency between the database and Quicksilver.

This is known as a full build. Full builds work great because each DNS record change corresponds to one zone change event. This means that multiple events can be batched and subsequently dropped if needed. For example, if a user makes 10 changes to their zone, this will result in 10 events. Since the Zone Builder grabs all the records for the zone anyway, there is no need to build the zone 10 times. We just need to build it once after the final change has been submitted.

What happens if the zone contains one million records or 10 million records? This is a very real problem, because not only is Cloudflare scaling, but our customers are scaling with us. Today our largest zone currently has millions of records. Although our database is optimized for performance, even one full build containing one million records took up to 35 seconds, largely caused by database query latency. In addition, when the Zone Builder compares the zone contents with the records stored in Quicksilver, we need to fetch all the records from Quicksilver for the zone, adding time. However, the impact doesn’t just stop at the single customer. This also eats up more resources from other services reading from the database and slows down the rate at which our Zone Builder can build other zones.

Per-record build: a new build type

Many of you might already have the solution to this problem in your head:

Why doesn’t the Zone Builder just query the database for the record that has changed and propagate just the single record?

Of course this is the correct solution, and the one we eventually ended up at. However, the road to get there was not as simple as it might seem.

Firstly, our database uses a series of functions that, at zone touch time, create a PostgreSQL Queue (PGQ) event that ultimately gets turned into a Kafka event. Initially, we had no distinction for individual record events, which meant our Zone Builder had no idea what had actually changed until it queried the database.

Next, the Zone Builder is still responsible for DNS zone settings in addition to records. Some examples of DNS zone settings include custom nameserver control and DNSSEC control. As a result, our Zone Builder needed to be aware of specific build types to ensure that they don’t step on each other. Furthermore, per-record builds cannot be batched in the same way that zone builds can because each event needs to be actioned separately.

As a result, a brand new scheduling system needed to be written. Lastly, Quicksilver interaction needed to be re-written to account for the different types of schedulers. These issues can be broken down as follows:

  1. Create a new Kafka event pipeline for record changes that contain information about the changed record.
  2. Separate the Zone Builder into a new type of scheduler that implements some defined scheduler interface.
  3. Implement the per-record scheduler to read events one by one in the correct order.
  4. Implement the new Quicksilver interface for the per-record scheduler.

Below is a high level diagram of how the new Zone Builder looks internally with the new scheduler types.

It is critically important that we lock between these two schedulers because it would otherwise be possible for the full build scheduler to overwrite the per-record scheduler’s changes with stale data.

It is important to note that none of this per-record architecture would be possible without the use of Cloudflare’s black lie approach to negative answers with DNSSEC. Normally, in order to properly serve negative answers with DNSSEC, all the records within the zone must be canonically sorted. This is needed in order to maintain a list of references from the apex record through all the records in the zone. With this normal approach to negative answers, a single record that has been added to the zone requires collecting all records to determine its insertion point within this sorted list of names.

Bugs

I would love to be able to write a Cloudflare blog where everything went smoothly; however, that is never the case. Bugs happen, but we need to be ready to react to them and set ourselves up so that next time this specific bug cannot happen.

In this case, the major bug we discovered was related to the cleanup of old records in Quicksilver. With the full Zone Builder, we have the luxury of knowing exactly what records exist in both the database and in Quicksilver. This makes writing and cleaning up a fairly simple task.

When the per-record builds were introduced, record events such as creates, updates, and deletes all needed to be treated differently. Creates and deletes are fairly simple because you are either adding or removing a record from Quicksilver. Updates introduced an unforeseen issue due to the way that our PGQ was producing Kafka events. Record updates only contained the new record information, which meant that when the record name was changed, we had no way of knowing what to query for in Quicksilver in order to clean up the old record. This meant that any time a customer changed the name of a record in the DNS Records API, the old record would not be deleted. Ultimately, this was fixed by replacing those specific update events with both a creation and a deletion event so that the Zone Builder had the necessary information to clean up the stale records.

None of this is rocket surgery, but we spend engineering effort to continuously improve our software so that it grows with the scaling of Cloudflare. And it’s challenging to change such a fundamental low-level part of Cloudflare when millions of domains depend on us.

Results

Today, all DNS Records API record changes are treated as per-record builds by the Zone Builder. As I previously mentioned, we have not been able to get rid of full builds entirely; however, they now represent about 13% of total DNS builds. This 13% corresponds to changes made to DNS settings that require knowledge of the entire zone’s contents.

When we compare the two build types as shown below we can see that per-record builds are on average 150x faster than full builds. The build time below includes both database query time and Quicksilver write time.

From there, our records are propagated to our global network through Quicksilver.

The 150x improvement above is with respect to averages, but what about that 4000x that I mentioned at the start? As you can imagine, as the size of the zone increases, the difference between full build time and per-record build time also increases. I used a test zone of one million records and ran several per-record builds, followed by several full builds. The results are shown in the table below:

Build TypeBuild Time (ms)
Per Record #16
Per Record #27
Per Record #36
Per Record #48
Per Record #56
Full #134032
Full #233953
Full #334271
Full #434121
Full #534093

We can see that, given five per-record builds, the build time was no more than 8ms. When running a full build however, the build time lasted on average 34 seconds. That is a build time reduction of 4250x!

Given the full build times for both average-sized zones and large zones, it is apparent that all Cloudflare customers are benefitting from this improved performance, and the benefits only improve as the size of the zone increases. In addition, our Zone Builder uses less database and Quicksilver resources meaning other Cloudflare systems are able to operate at increased capacity.

Next Steps

The results here have been very impactful, though we think that we can do even better. In the future, we plan to get rid of full builds altogether by replacing them with zone setting builds. Instead of fetching the zone settings in addition to all the records, the zone setting builder would just fetch the settings for the zone and propagate that to our global network via Quicksilver. Similar to the per-record builds, this is a difficult challenge due to the complexity of zone settings and the number of actors that touch it. Ultimately if this can be accomplished, we can officially retire the full builds and leave it as a reminder in our git history of the scale at which we have grown over the years.

In addition, we plan to introduce a batching system that will collect record changes into groups to minimize the number of queries we make to our database and Quicksilver.

Does solving these kinds of technical and operational challenges excite you? Cloudflare is always hiring for talented specialists and generalists within our Engineering and other teams.

Source :
https://blog.cloudflare.com/dns-build-improvement/

How the Saitama backdoor uses DNS tunnelling

Thanks to the Malwarebytes Threat Intelligence Team for the information they provided for this article.

Understandably, a lot of cybersecurity research and commentary focuses on the act of breaking into computers undetected. But threat actors are often just as concerned with the act of breaking out of computers undetected too.

Malware with the intent of surveillance or espionage needs to operate undetected, but the chances are it also needs to exfiltrate data or exchange messages with its command and control infrastructure, both of which could reveal its presence to threat hunters.

One of the stealthy communication techniques employed by malware trying to avoid detection is DNS Tunnelling, which hides messages inside ordinary-looking DNS requests.

The Malwarebytes Threat Intelligence team recently published research about an attack on the Jordanian government by the Iranian Advanced Persistent Threat (APT) group APT34 that used its own innovative version of this method.

The payload in the attack was a backdoor called Saitama, a finite state machine that used DNS to communicate. Our original article provides an educational deep dive into the operation of Saitama and is well worth a read.

Here we will expand on the tricks that Saitama used to keep its DNS tunelling hidden.

Saitama’s DNS tunnelling

DNS is the Internet’s “address book” that allows computers to lookup human-readable domain names, like malwarebytes.com, and find their IP addresses, like 54.192.137.126.

DNS information isn’t held in a single database. Instead it’s distributed, and each domain has name servers that are responsible for answering questions about them. Threat actors can use DNS to communicate by having their malware make DNS lookups that are answered by name servers they control.

DNS is so important it’s almost never blocked by corporate firewalls, and the enormous volume of DNS traffic on corporate networks provides plenty of cover for malicious communication.

Saitama’s messages are shaped by two important concerns: DNS traffic is still largely unencrypted, so messages have to be obscured so their purpose isn’t obvious; and DNS records are often cached heavily, so identical messages have to look different to reach the APT-controlled name servers.

Saitama’s messages

In the attack on the Jordanian foreign ministry, Saitama’s domain lookups used the following syntax:

domain = message, counter '.' root domain

The root domain is always one of uber-asia.com, asiaworldremit.com or joexpediagroup.com, which are used interchangeably.

The sub-domain portion of each lookup consists of a message followed by a counter. The counter is used to encode the message, and is sent to the command and control (C2) server with each lookup so the C2 can decode the message.

Four types of message can be sent:

1. Make contact

The first time it is executed, Saitama starts its counter by choosing a random number between 0 and 46655. In this example our randomly-generated counter is 7805.

The DNS lookup derived from that counter is:

nbn4vxanrj.joexpediagroup.com

The counter itself is encoded using a hard-coded base36 alphabet that is shared by the name server. In base36 each digit is represented by one of the 36 characters 0-9 and A-Z. In the standard base36, alphabet 7805 is written 60t (6 x 1296 + 0 x 36 + 30 x 1). However, in Saitama’s custom alphabet 7805 is nrj.

The counter is also used to generate a custom alphabet that will be used to encode the message using a simple substitution. The first message sent home is the command 0, base36-encoded to a, which tells the server it has a new victim, prepended to the string haruto, making aharuto.

A simple substitution using the alphabet generated by the counter yields the message nbn4vxa.

a b c d e f g h i j k l m n o p q r s t u v w x y z 0 1 2 3 4 5 6 7 8 9
↓             ↓             ↓     ↓   ↓ ↓             
n j 1 6 9 k p b h d 0 7 y i a 2 g 4 u x v 3 e s w f 5 8 r o c q t l z m

The C2 name server decodes the counter using the shared, hard-coded alphabet, and then uses the counter to derive the alphabet used to encode aharuto.

It responds to the contact request with an IP address that contains an ID for Saitama to use in future communications. The first three octets can be anything, and Saitama ignores them. The final octet contains the ID. In our example we will use the ID 203:

75.99.87.203

2. Ask for a command

Now that it has an ID from the C2 server, Saitama increments its counter to 7806 and signals its readiness to receive a command as follows: The counter is used to generate a new custom alaphabet, which encodes the ID, 203, as ao. The counter itself is encoded using the malware’s hard-coded base36 alphabet, to nrc, and one of Saitama’s three root domains is chosen at random, resulting in:

aonrc.uber-asia.com

The C2 server responds to the request with the size of the payload Saitama should expect. Saitama will use this to determine how many requests it will need to make to retrieve the full payload.

The first octet of the IP address the C2 responds with is any number between 129 and 255, while the second, third and fourth octets signify the first, second, and third bytes of the size of the payload. In this case the payload will be four bytes.

129.0.0.4

3. Get a command

Now that it knows the size of the payload it will receive, Saitama makes one or more RECEIVE requests to the server to get its instructions. It increments its counter by one each time, starting at 7807. Multiple requests may be necessary in this step because some command names require more than the four bytes of information an IP address can carry. In this case it has been told to retrieve four bytes of information so it will only need to make one request.

The message from Saitama consists of three parts: The digit 2, indicating the RECEIVE command; the ID 203; and an offset indicating which part of the payload is required. These are individually base36-encoded and concatenated together. The resulting string is encoded using a custom base36 alphabet derived from the counter 7807, giving us the message k7myyy.

The counter is encoded using the hard-coded alphabet to nr6, and one of Saitama’s three root domains is chosen at random, giving us:

k7myyynr6.asiaworldremit.com

The C2 indicates which function it wants to run using two-digit integers. It can ask Saitama to run any of five different functions:

C2Saitama
43Static
70Cmd
71CompressedCmd
95File
96CompressedFile

Saitama functions

In this case the C2 wants to run the command ver using Saitama’s Cmd function. (In the previous request the C2 indicated that it would be sending Saitama a four byte payload: One byte for 70, and three bytes for ver.)

In its response, the C2 uses the first octet of the IP address to indicate the function it wants to run, 70, and then the remaining three octets to spell out the command name ver using the ASCII codepoints for the lowercase characters “v”, “e”, and “r”:

70.118.101.114

4. Run the command

Saitama runs the command it has been given and sends the resulting output to the C2 server in one or more DNS requests. The counter is incremented by one each time, starting at 7808 in our example. Multiple requests may be necessary in this step because some command names require more than the four bytes an IP address can carry.

p6yqqqqp0b67gcj5c2r3gn3l9epztnrb.asiaworldremit.com

The counter is encoded using the hard-coded alphabet to nrb, and one of Saitama’s three root domains is chosen at random.

In this case the message consists of five parts: The digit 2, indicating the RECEIVE command; the ID 203; and an offset indicating which part of the response is being sent; the size of the buffer; and a twelve-byte chunk of the output. These are individually base36-encoded and concatenated together. The resulting string is encoded using a custom base36 alphabet derived from the counter 7808, giving us the message p6yqqqqp0b67gcj5c2r3gn3l9epzt.

Detection

Malwarebytes customers are protected from this attack via our Anti-Exploit layer. To learn more about the recent attack involving Saitama, read APT34 targets Jordan Government using new Saitama backdoor.

IOCs

Maldoc

Confirmation Receive Document.xls
26884f872f4fae13da21fa2a24c24e963ee1eb66da47e270246d6d9dc7204c2b

Saitama backdoor

update.exe
e0872958b8d3824089e5e1cfab03d9d98d22b9bcb294463818d721380075a52d

C2s

uber-asia.com
asiaworldremit.com
joexpediagroup.com

Source :
https://blog.malwarebytes.com/threat-intelligence/2022/05/how-the-saitama-backdoor-uses-dns-tunnelling/

New in SecureX: Device Insights

Since its release, Cisco SecureX has helped over 10,000 customers gain better visibility into their infrastructure. As the number of devices in many customer environments continues to increase, so does the number of products with information about those devices. Between mobile device managers (MDM), posture agents, and other security products, a wealth of data is being collected but is not necessarily being shared or, more importantly, correlated. With the new device insights feature in Cisco SecureX, now available for all SecureX customers, we’re changing that.

Introducing Device Insights

Device insights, which is now generally available, extends our open, platform approach to SecureX by allowing you to discover, normalize, and consolidate information about the devices in your environment. But this isn’t just another dashboard pulling data from multiple sources. Device insights fetches data from sources you might expect, like your mobile device manager, but also leverages the wealth of data available in your Cisco Secure products such as Cisco Secure Endpoint, Orbital, Duo, and Umbrella. Combining these sources of data allows you to discover devices that may be sneaking through gaps in your normal device management controls and gain a comprehensive view into each device’s security posture and management status. With device insights, you’ll be able to answer these all-important questions:

  • What types of devices are connected in our environment?
  • What users have been accessing those devices?
  • Where are those devices located?
  • What vulnerabilities are associated with each device?
  • Which security agents are installed?
  • Is the security software is up to date?
  • What context do we have from technologies beyond the endpoint?

Supported Data Sources

Now, you might ask: what types of data can I bring into device insights? When we created SecureX, we built a flexible architecture based on modules that anyone can create. Device insights extends this architecture by adding a new capability to our module framework. Here’s a look at what data sources will be supported at launch:

Bringing Everything Together

Once you’ve enabled your data sources, device insights will periodically retrieve data from each source and get to work. Some sources can also publish data in real time to device insights using webhooks. We normalize all of the data and then correlate it between sources so you have one view into each of your devices, not a mess of duplicate information. This results in a single, unified dashboard with easy filtering, a high level view into your environment, and a customizable table of devices (which you can export too!). To see more information about a device, just click on one and you’ll see everything device insights knows, including which source provided which data.

screenshot: SecureX device status dashboard
screenshot: SecureX device detail view

Getting Started

To get started with device insights, simply log into Cisco SecureX and click the new Insights tab! For more information about device insights, check out these resources:

NIST Releases Updated Cybersecurity Guidance for Managing Supply Chain Risks

The National Institute of Standards and Technology (NIST) on Thursday released an updated cybersecurity guidance for managing risks in the supply chain, as it increasingly emerges as a lucrative attack vector.

“It encourages organizations to consider the vulnerabilities not only of a finished product they are considering using, but also of its components — which may have been developed elsewhere — and the journey those components took to reach their destination,” NIST said in a statement.

The new directive outlines major security controls and practices that entities should adopt to identify, assess, and respond to risks at different stages of the supply chain, including the possibility of malicious functionality, flaws in third-party software, insertion of counterfeit hardware, and poor manufacturing and development practices.

Software Supply Chain Risks

The development follows an Executive Order issued by the U.S. President on “Improving the Nation’s Cybersecurity (14028)” last May, requiring government agencies to take steps to “improve the security and integrity of the software supply chain, with a priority on addressing critical software.”

Supply Chain Risks

It also comes as cybersecurity risks in the supply chain have come to the forefront in recent years, in part compounded by a wave of attacks targeting widely-used software to breach dozens of downstream vendors all at once.

According to the European Union Agency for Cybersecurity’s (ENISA) Threat Landscape for Supply Chain Attacks, 62% of 24 attacks documented from January 2020 to early 2021 were found to “exploit the trust of customers in their supplier.”

“Managing the cybersecurity of the supply chain is a need that is here to stay,” said NIST’s Jon Boyens and one of the publication’s authors. “If your agency or organization hasn’t started on it, this is a comprehensive tool that can take you from crawl to walk to run, and it can help you do so immediately.”

Source :
https://thehackernews.com/2022/05/nist-releases-updated-guidance-for.html

Cloudflare Thwarts Record DDoS Attack Peaking at 15 Million Requests Per Second

Cloudflare on Wednesday disclosed that it acted to mitigate a 15.3 million request-per-second (RPS) distributed denial-of-service (DDoS) attack. The web infrastructure and website security company called it one of the “largest HTTPS DDoS attacks on record.”

“HTTPS DDoS attacks are more expensive in terms of required computational resources because of the higher cost of establishing a secure TLS encrypted connection,” Cloudflare’s Omer Yoachimik and Julien Desgats said. “Therefore it costs the attacker more to launch the attack, and for the victim to mitigate it.”

The volumetric DDoS attack is said to have lasted less than 15 seconds and targeted an unnamed Cloudflare customer operating a crypto launchpad.

Volumetric DDoS attacks are designed to overwhelm a target network/service with significantly high volumes of malicious traffic, which typically originate from a botnet under a threat actor’s control.

distributed denial-of-service (DDoS) attack

Cloudflare said the latest attack was launched from a botnet consisting of roughly 6,000 unique compromised devices, with 15% of the attack traffic emanating from Indonesia, followed by Russia, Brazil, India, Colombia, and the U.S.

“What’s interesting is that the attack mostly came from data centers,” Yoachimik and Desgats noted. “We’re seeing a big move from residential network Internet Service Providers (ISPs) to cloud compute ISPs.”

Record-setting DDoS attacks have become increasingly common in recent months. In August 2021, Cloudflare disclosed what it characterized as the largest application-layer attack ever seen, and, earlier this year, Microsoft revealed that it had prevented multiple DDoS attacks that crossed 2.4 terabits per second (Tbps).

In addition, cybersecurity firm Kaspersky revealed this week that the number of DDoS attacks hit an all-time high in the first quarter of 2022, jumping 4.5 times year-over-year, largely driven by Russia’s invasion of Ukraine.

“The DDoS attack landscape in Q1 was strongly influenced by the geopolitical situation: since the end of February, we have seen a surge in hacktivist activity and the emergence of a large number of spontaneous botnets that users connected to voluntarily,” the Russian company said.

Source :
https://thehackernews.com/2022/04/cloudflare-thwarts-record-ddos-attack.html

Unpatched DNS Related Vulnerability Affects a Wide Range of IoT Devices

Cybersecurity researchers have disclosed an unpatched security vulnerability that could pose a serious risk to IoT products.

The issue, which was originally reported in September 2021, affects the Domain Name System (DNS) implementation of two popular C libraries called uClibc and uClibc-ng that are used for developing embedded Linux systems.

uClibc is known to be used by major vendors such as Linksys, Netgear, and Axis, as well as Linux distributions like Embedded Gentoo, potentially exposing millions of IoT devices to security threats.

“The flaw is caused by the predictability of transaction IDs included in the DNS requests generated by the library, which may allow attackers to perform DNS poisoning attacks against the target device,” Giannis Tsaraias and Andrea Palanca of Nozomi Networks said in a Monday write-up.

DNS poisoning, also referred to as DNS spoofing, is the technique of corrupting a DNS resolver cache — which provides clients with the IP address associated with a domain name — with the goal of redirecting users to malicious websites.

The vulnerability in uClibc and uClibc-ng is the result of having a predictable transaction ID assigned to each DNS lookup and their static use of source port 53, effectively defeating source port randomization protections.

Successful exploitation of the bug could allow an adversary to carry out Man-in-the-Middle (MitM) attacks and corrupt the DNS cache, effectively rerouting internet traffic to a server under their control.

Nozomi Networks cautioned that the vulnerability could be trivially exploited in a reliable manner should the operating system be configured to use a fixed or predictable source port.

“The attacker could then steal and/or manipulate information transmitted by users, and perform other attacks against those devices to completely compromise them,” the researchers said.

Source :
https://thehackernews.com/2022/05/unpatched-dns-related-vulnerability.html

Cybersecurity Threat Spotlight: HermeticWiper, SDUser, and Xenomorph

This has been a busy month for cyber attackers, and the Cisco Umbrella team – in conjunction with Cisco Talos – has observed several new threats for users to be aware of.

In this month’s edition of the Cybersecurity Threat Spotlight, we discuss a wiper making its way through Ukraine, a dropper targeting India and China, and a newly discovered Trojan targeting EU banks.

Want to see Cisco Umbrella in action? Sign up for a free trial today!

HermeticWiper

Threat Type: Wiper

Attack Chain:

Graphic showing the attack chain for HermeticWiper. The attack chain proceeds as follows: stolen credentials, network access, direct wiper deployment, data destruction. The graphic indicates that Cisco Secure protects users from stolen credentials and data destruction.

Description: HermeticWiper is a data destructing malware observed in attacks targeting Ukraine. This wiper comes as a small executable with a valid digital signature issued to “Hermetica Digital Ltd.” The malware leverages embedded resources to interact with storage devices present on infected systems. The applicable embedded driver is extracted, loaded into the wiper’s process memory space, decompressed, and written to the disk before the wipe process. The wiper disables the generation of crash dumps and corrupts the first 512 bytes to destroy the MBR of physical drives. For partitions, it disables the Volume Shadow Copy Service and uses different destructive mechanisms on the partitions depending on whether they’re FAT type or NTFS type. The wiper also attempts to corrupt housekeeping files. During the final stage, HermeticWiper waits for all sleeping threads to complete and initiates a reboot to ensure the success of the wiping activity.

HermeticWiper Spotlight: Cisco Talos has become aware of a series of wiper attacks going on inside Ukraine. One of the wipers used in these attacks has been dubbed “HermeticWiper.” Deployment of this destructive malware began on February 23, 2022. The malware has two components designed for destruction: one targeting the Master Boot Record (MBR) and another targeting partitions.

Target Geolocations: Ukraine
Target Data: Physical Drivers, Partitions
Target Businesses: Government Sector
Exploits: N/A

Mitre ATT&CK for HermeticWiper

Initial Access:
Valid Accounts

Discovery:
System Information Discovery
File and Directory Discovery

Persistence:
Create or Modify System Process: Windows Service

Execution:
Native API

Evasion:
Modify Registry

Impact:
Disk Wipe: Disk Structure Wipe
Inhibit System Recovery
Service Stop
System Shutdown/Reboot

Privilege Escalation:
Access Token Manipulation

IOCs1

Hashes:
0385eeab00e946a302b24a91dea4187c1210597b8e17cd9e2230450f5ece21da
1bc44eef75779e3ca1eefb8ff5a64807dbc942b1e4a2672d77b9f6928d292591
2c10b2ec0b995b88c27d141d6f7b14d6b8177c52818687e4ff8e6ecf53adf5bf
3c557727953a8f6b4788984464fb77741b821991acbf5e746aebdd02615b1767

Additional Information
Threat Advisory: Hermetic Wiper

Which Cisco Secure Products Can Block
Cisco Secure Endpoint
Cisco Secure Email
Cisco Secure Firewall/Secure IPS
Cisco Secure Malware Analytics
Cisco Umbrella

SDUser

Threat Type: Dropper

Attack Chain:

A graphic showing the attack chain of SDUser, which is as follows: malspam to download weaponized document to malicious macros to SDUser payload to follow-up malware. The graphic indicates that Cisco Secure products protect users from downloading weaponized documents and follow-up malware.

Description: SDUser is a VBA-based dropper that is used by Advanced Persistent Threat (APT) groups. The functionality of the payload includes command and control protocol, anti-sandboxing techniques, and a reverse shell mechanism.

SDUser Spotlight: In June 2021, Cisco Talos researchers discovered a malicious Excel spreadsheet that attempted to drop a previously unknown RAT. A month later, they discovered another closely related spreadsheet. These samples were internally referred to as “SDUser” sampled due to the specific PDB string left in the binary payload.

More recent analysis shows similar code being used by two different APT groups: Transparent Tribe, which targets organizations in India, and Donut, which targets organizations in Pakistan and China. These two different threat actors may use code from the same source in their attacks, which means that their attacks would display similarities despite being conducted by different groups. Code reuse, adopting techniques from successful attacks, and deliberate integration of evidence designed to fool analysts can disguise the true perpetrator and lead to these attacks being attributed to different groups.

Target Geolocations: Pakistan, China
Target Data: User Credentials, Browser Data, Sensitive Information
Target Businesses: Any
Exploits: N/A

Mitre ATT&CK for SDUser

Initial Access:
Phishing: Spearphishing Attachment

Discovery:
Peripheral Device Discovery
Query Registry

Execution:
Command and Scripting Interpreter

Evasion:
Obfuscated Files or Information
Virtualization/Sandbox Evasion: System Checks

Command and Control:
Application Layer Protocol
Web Service

IOCs1

Domains:
microsoft-updates[.]servehttp[.]com
microsoft-patches[.]servehttp[.]com
microsoft-docs[.]myftp[.]org

IPs:
45.153.240[.]66
46.30.188[.]222

Additional Information:
What’s with the shared VBA code between Transparent Tribe and other threat actors?

Which Cisco Secure Products Can Block:
Cisco Secure Endpoint
Cisco Secure Email
Cisco Secure Firewall/Secure IPS
Cisco Secure Malware Analytics
Cisco Umbrella
Cisco Secure Web Appliance

Xenomorph

Threat Type: Mobile Trojan

Attack Chain:

A graphic showing the attack chain of Xenomorph, which is as follows: Trojanized app to data logging to data exfiltration. The graphic indicates that Cisco Secure products protect against data exfiltration.

Description: Xenomorph is an Android Banking Trojan. It is capable of stealing credentials via overlay attack, and it uses SMS and notification interception to log and use potential 2FA tokens. Stolen data is sent to the C2 for further exploitation.

Xenomorph Spotlight: Xenomorph was initially discovered in February 2022. It is distributed through the official Google Play Store. It targets users of 56 different European banks and cryptocurrency wallets. Capabilities include – but are not limited to – stealing credentials, SMS and notification interception, excessive logging, and data exfiltration. The core engine is designed as a modular system and still appears to be in the development stage. Malware heavily relies on the overlay attack mechanism to steal personally identifiable information (PII) and other sensitive data. Collected data is exfiltrated to an attacker-controlled server using the open-source project RetroFit2.

Target Geolocations: EU
Target Data: User Credentials, Browser Data, Sensitive Information
Target Businesses: Any
Exploits: N/A

Mitre ATT&CK for Xenomorph

Initial Access:
Deliver Malicious App via Authorized App Store

Execution:
Native Code

Evasion:
Masquerading as Legitimate Application

Credential Access:
Capture SMS Messages
Input Capture

Command and Control:
Standard Application Layer Protocol

Exfiltration:
Data Encryption
Standard Application Layer Protocol

IOCs1

Domains:
simpleyo5[.]tk   
simpleyo5[.]cf   
art12sec[.]ga    
kart12sec[.]gq   
homeandofficedeal[.]com

Additional Information:
Xenomorph: A newly hatched Banking Trojan

Which Cisco Secure Products Can Block
Cisco Secure Firewall/Secure IPS
Cisco Secure Malware Analytics
Cisco Umbrella
Cisco Secure Web Appliance

Source :
https://umbrella.cisco.com/blog/cybersecurity-threat-spotlight-hermeticwiper-sduser-xenomorph