The idea of monetizing distributed denial-of-service (DDoS) attacks dates back to the 1990s. But the rise of DDoS-for-hire services and cryptocurrencies has radically changed the landscape.
Errol will talk about his experiences with information sharing and building the world’s first Information Sharing & Analysis Center in 1999. Errol brings unique perspective to the table as he was the service provider behind the Financial Services ISAC, then a subscriber and ISAC member for 13 years in the banking and finance sector.
Segment Resources:
National Council of ISACs – great resource to find out about all the different ISACs
https://www.nationalisacs.org/
Information Sharing Best Practices Toolkit:
https://h-isac.org/h-isac-information-sharing-best-practices/
Visit https://www.securityweekly.com/scw for all the latest episodes!
Show Notes: https://securityweekly.com/scw68
Breaches, Microsoft, the Dead Return to Life, The IRS is coming for your Bitcoin, Have YOU been PWNed, and the Expert Commentary of none other than Jason Wood!
Time Stamps:
1:56 – IRS Initiates ‘Operation Hidden Treasure’ to Root Out Unreported Crypto Income
4:06 – 533M Facebook Accounts Leaked Online: Check if You Are Exposed
-Check if you’ve Been PWN’d : https://haveibeenpwned.com/
6:40 – LinkedIn Spear-Phishing Campaign Targets Job Hunters
7:52 – Ransom Gangs Emailing Victim Customers for Leverage
8:48 – New Microsoft Edge grew 1,300% this year, overtaking Firefox
10:58 – Microsoft Defender for Endpoint now supports Windows 10 Arm devices
12:35 – Twitter nixes a handful of accounts pretending to be happy Amazon workers
14:55- Commercial Break & Jason Wood!
23:11 – ‘Deep Nostalgia’ Can Now Make Old Photos of Your Relatives Dance and Blow Kisses
Visit https://www.securityweekly.com/swn for all the latest episodes!
As tensions between Azerbaijan and Armenia continue, we are still seeing a number of cyber attacks taking advantage of this situation. On March 5th 2021, we reported an actor that used steganography to drop a new .Net Remote Administration Trojan. Since that time, we have been monitoring this actor and were able to identify new activity where the threat actor switched their RAT from .Net to Python.
Document Analysis
The document targets the government of Azerbaijan using a SOCAR letter template as lure. SOCAR is the name of Azerbaijan’s Republic Oil and Gas Company. The document’s date is 25th March 2021 and the letter, related to export of catalyst for analysis, is written to the Ministry of Ecology and Natural Resources. The document’s creation time is 28th March 2021 and is aligned with the date mentioned on the letter. Based on the dates we believe that this attack happened between 28th and 30th of March 2021.
Figure 1: Document lure
The embedded macro in this document is almost similar to what we have reported before with some small differences. We will talk about the similarities between these two documents in the next section.
The macro has two main functions “Document_Open” and “Document_Close”. In “Document_Open” after defining the required variables it creates a directory (%APPDATA%Roamingnettools48) for its Python Rat.
Figure 2: Document_Open
It then copies itself in a new format to the file path defined before in order to be able to extract the required data from an embedded PNG file (image1.png).
Figure 3: Embedded image
To extract the embedded data, it calls the “ExtractFromPng” function to identify the chunk that has the embedded data. After finding the chunk, it extracts the files from the PNG file and writes them into “tmp.zip”.
Figure 4: Chunk identification
The “tmp.zip” is then extracted into “%APPDATA%Roamingnettools48” directory. It contains the Python 3.6 interpreter, NetTools Python library, Python Rat, the RAT C2 config, as well runner.bat.
Figure 5: Application directory
The Python Rat will be executed when the document is closed. The “Document_Close” first delays execution to bypass security detection mechanisms by creating a junk loop for 100 times and then executes the runner.bat by calling Shell function.
Figure 6: Document_Close
The runner.bat is also delaying execution for 64 seconds and then it calls Python to execute the Python RAT (vabsheche.py)
SET /A num=%RANDOM% * (80 - 60 + 1) / 32768 + 60
timeout /t %num%
set DIR=%~dp0
"%DIR%python" "%DIR%vabsheche.py"
Python RAT Analysis
The Python RAT used by the attacker is not obfuscated and is pretty simple. It is using the platform library to identify the victim’s OS type.
Figure 7: OS identification
The C2 domain and port are hardcoded within a file in the RAT directory. The RAT opens this file and extracts the host and port from this file.
Figure 8: Reads C2 config
In the next step if the victim is running Windows, it makes itself persistent through creating a scheduled task. It first checks if a scheduled task with the name “paurora*” exists or not. If it does not exist, it reads the content of bg.txt file and creates a bg.vbs file. Then adds the created VBS file to the list of scheduled tasks.
Figure 9: Creates Scheduled task
The created VBS file calls the runner.bat to execute the Python RAT.
Figure 10: Scheduled task
The main functionality of the RAT is through a loop that starts by creating a secure SSL connection to the server using a certificate file (cert.pem) that was extracted from the PNG file and dropped into the RAT directory.
Figure 11: Makes secure connection to server
After building the secure connection to the server it goes to a loop that receives a message from the server and executes different commands based on the message type.
Figure 12: Executes commands
Here is the list of commands that can be executed by the RAT:
OPEN_NEW_CONNECTION: Sends a message to the server with False as content
HEART_BEAT: Sends a message to the server that the victim is alive
USER_INFO: Collects victim info including OS Name, OS Version and User Name
SHELL: Executes shell commands received from the server
PREPARE_UPLOAD: Checks if it can open a file to write the received data from server into it and if that is the case it sends a “Ready” message to the server
UPLOAD: Receives a buffer from the server and writes them into file
DOWNLOAD: Archives files and sends them to the server
Similarity Analysis
In this sections we provide the similarities between two documents and TTPs used by them. This will help hunters to identify the future campaigns associated with this actor.
TTPs similarities
Used steganography to embed RATs within the embedded images.
Used scheduled tasks for persistence. In both cases It created a VBS file to execute the batch runner.
Used a batch file with the same name (runner.bat) to execute the final RAT.
Used the same technique to exfiltrate data. (Archive them and send them to the server)
Documents similarities
Both have been obfuscated using same obfuscation techniques: Inserting random characters within the meaningful names to obfuscate the functions and variables names. After deobfuscation, the function graph of these two documents are almost similar.
Figure 13: Socar.doc
Figure 14: telebler.doc
Both have used the similar method to obfuscate strings: using “MyFunc23” function that receives an array of numbers and decodes them into a string.
Other similarities
both C2 domains have resolved to the same IP address.
There are overlaps between the commands used by both .Net and Python RATs.
Conclusion
Due to tensions between Azerbaijan and Armenia, cyber attacks against these countries have been increasing in the past year. The Malwarebytes Threat Intelligence Team is constantly monitoring actors that are targeting these countries and was able to identify an actor that has targeted Azerbaijan using different RATs. This actor has used .Net and Python RATs to infect victims and steal data from them. The actor used spear phishing as initial vector that has used steganography to drop a variant of its RATs.
Ne’er-do-wells leaked personal data — including phone numbers — for some 553 million Facebook users this week. Facebook says the data was collected before 2020 when it changed things to prevent such information from being scraped from profiles. To my mind, this just reinforces the need to remove mobile phone numbers from all of your online accounts wherever feasible. Meanwhile, if you’re a Facebook product user and want to learn if your data was leaked, there are easy ways to find out.
Ne’er-do-wells leaked personal data — including phone numbers — for some 553 million Facebook users this week. Facebook says the data was collected before 2020 when it changed things to prevent such information from being scraped from profiles. To my mind, this just reinforces the need to remove mobile phone numbers from all of your online accounts wherever feasible. Meanwhile, if you’re a Facebook product user and want to learn if your data was leaked, there are easy ways to find out.
The HaveIBeenPwned project, which collects and analyzes hundreds of database dumps containing information about billions of leaked accounts, has incorporated the data into his service. Facebook users can enter the mobile number (in international format) associated with their account and see if those digits were exposed in the new data dump (HIBP doesn’t show you any data, just gives you a yes/no on whether your data shows up).
The phone number associated with my late Facebook account (which I deleted in Jan. 2020) was not in HaveIBeenPwned, but then again Facebook claims to have more than 2.7 billion active monthly users.
It appears much of this database has been kicking around the cybercrime underground in one form or another since last summer at least. According to a Jan. 14, 2021 Twitter post from Under the Breach’s Alon Gal, the 533 million Facebook accounts database was first put up for sale back in June 2020, offering Facebook profile data from 100 countries, including name, mobile number, gender, occupation, city, country, and marital status.
Under The Breach also said back in January that someone had created a Telegram bot allowing users to query the database for a low fee, and enabling people to find the phone numbers linked to a large number of Facebook accounts.
A cybercrime forum ad from June 2020 selling a database of 533 Million Facebook users. Image: @UnderTheBreach
Many people may not consider their mobile phone number to be private information, but there is a world of misery that bad guys, stalkers and creeps can visit on your life just by knowing your mobile number. Sure they could call you and harass you that way, but more likely they will see how many of your other accounts — at major email providers and social networking sites like Facebook, Twitter, Instagram, e.g. — rely on that number for password resets.
From there, the target is primed for a SIM-swapping attack, where thieves trick or bribe employees at mobile phone stores into transferring ownership of the target’s phone number to a mobile device controlled by the attackers. From there, the bad guys can reset the password of any account to which that mobile number is tied, and of course intercept any one-time tokens sent to that number for the purposes of multi-factor authentication.
Or the attackers take advantage of some other privacy and security wrinkle in the way SMS text messages are handled. Last month, a security researcher showed how easy it was to abuse services aimed at helping celebrities manage their social media profiles to intercept SMS messages for any mobile user. That weakness has supposedly been patched for all the major wireless carriers now, but it really makes you question the ongoing sanity of relying on the Internet equivalent of postcards (SMS) to securely handle quite sensitive information.
My advice has long been to remove phone numbers from your online accounts wherever you can, and avoid selecting SMS or phone calls for second factor or one-time codes. Phone numbers were never designed to be identity documents, but that’s effectively what they’ve become. It’s time we stopped letting everyone treat them that way.
Any online accounts that you value should be secured with a unique and strong password, as well as the most robust form of multi-factor authentication available. Usually, this is a mobile app like Authy or Google Authenticator that generates a one-time code. Some sites like Twitter and Facebook now support even more robust options — such as physical security keys.
Removing your phone number may be even more important for any email accounts you may have. Sign up with any service online, and it will almost certainly require you to supply an email address. In nearly all cases, the person who is in control of that address can reset the password of any associated services or accounts– merely by requesting a password reset email.
Unfortunately, many email providers still let users reset their account passwords by having a link sent via text to the phone number on file for the account. So remove the phone number as a backup for your email account, and ensure a more robust second factor is selected for all available account recovery options.
Here’s the thing: Most online services require users to supply a mobile phone number when setting up the account, but do not require the number to remain associated with the account after it is established. I advise readers to remove their phone numbers from accounts wherever possible, and to take advantage of a mobile app to generate any one-time codes for multifactor authentication.
Why did KrebsOnSecurity delete its Facebook account early last year? Sure, it might had something to do with the incessant stream of breaches, leaks and privacy betrayals by Facebook over the years. But what really bothered me were the number of people who felt comfortable sharing extraordinarily sensitive information with me on things like Facebook Messenger, all the while expecting that I can vouch for the privacy and security of that message just by virtue of my presence on the platform.
In case readers want to get in touch for any reason, my email here is krebsonsecurity at gmail dot com, or krebsonsecurity at protonmail.com. I also respond at Krebswickr on the encrypted messaging platform Wickr.
In a connected, but still remote, world, employees are logging in from countless devices and locations. Behaviors that were once uncommon – like accessing the corporate network on multiple or personal devices – are commonplace today. Driven by the expansion of a remote workforce, COVID-19 work-from-home orders and an exploding SaaS market, organizations everywhere are..
It is no secret that early security testing is beneficial. However, do you know how advantageous it is and what are the potential consequences of the lack of early testing? Here are 5 top benefits of early security testing along with the risks of late…
Sometimes we grow to like the old software we’ve become familiar with over the years, but because as users we only see the facade of an interface and functionality, we don’t know what risks may exist in something as simple as a clock. The bar is high for enterprise software: we have to expect that our software accomplishes all of its tasks in a manner that doesn’t put us at risk. Today we dive into a venerable piece of software that appears to carry out its underappreciated task, because despite the engineering behind its functionality, it contained a classic software flaw.
Domain Time II from Greyware Automation Products, Inc. is enterprise-grade time synchronization software, including client and server software as well as testing, administration, and auditing capabilities. Everyone has probably had a moment when they realized that the clocks on two different devices were off by a few minutes (or more), but some businesses are particularly sensitive to this issue and need to ensure that their computer systems are as closely synchronized as possible.
While this might seem like a boring problem, it actually requires a fair bit of work to keep computers’ clocks in sync; so much so that it’s a well-known issue in computing with a number of protocols and approaches for solving it to different precisions. In addition to implementing some of the more well known protocols such as NTP, Domain Time II implements it’s own high-precision protocol that can provide a tiered approach to serving time with clients and a hierarchy of servers.
All of this organization is very convenient, but it does require administering and trusting the software that runs on all the clients and servers you want synchronized. The difficulty with trust and software is that the authors have to get things right all the time, as well as be familiar with the tactics an attacker would use. Otherwise they end up in a situation like we found, where a weakness was obviously visible if one knew where to look… This time it’s an area that is overlooked by many, but rarely ignored by attackers: the update process. Most people know that updates are important for security, but typically only attackers and experts bother to look at the security of an update process itself and understand what a motivated attacker could do.
If you’ve never heard of a Man-on-the-Side (MotS) attack, it’s really just a variant of the classic Man-in-the-Middle (MitM) attack, where the attacker can inspect and control the communication flowing between two parties. In a MotS, the attacker can inspect but not control the data, though they may be able to respond to traffic they see. This attack is more easily achieved than a full MitM (think of any time you get on unencrypted WiFi, for example), but is also usually easily foiled by the use of encryption by the participants. Concerns over these kinds of attacks have led to the widespread adoption of Secure Hypertext Transfer Protocol (HTTPS) and Transport Layer Security (TLS). Without such encryption, any communication that can be eavesdropped at any point along the path of network communication could potentially be vulnerable, especially connectionless User Datagram Protocol (UDP) traffic like that used in the upgrade process for Domain Time II.
Bug identification
Domain Time II upgrade attack
Vulnerability Type: Unauthenticated Upgrade Process
Location: dttray.exe
Affected Versions: Domain Time II versions 5.2.x (current releases), 5.1.x (starting from 2010), and 4.1.x (starting from 2007) from 5.2.b.20210103 to at least 4.1.b.20070308
Impact: Potential Download and Execution of Malicious Payloads
CVE Number: TBD
The Domain Time II Client and Server programs both use the same executable, dttray.exe, to check for updates. Neither program automatically checks for updates by default, but both can be set to check for updates on startup or can be instructed to check for an update manually. Additionally, the Domain Time II Update Server component, if installed, does automatically check for updates whenever the Domain Time II Manager is opened.
Figure 1: Disassembly of client processing upgrade response
In all update cases, dttray.exe will send a UDP query to the update server to see if an update is available. If the server responds with a Uniform Resource Locator (URL) (i.e. it begins with “http://” or “https://”), the software will open a dialog box notifying a user that an update is available. If the user accepts the dialog, the software calls ShellExecuteA with the “open” argument on the URL returned by the server. This causes a browser window to open and navigate to the provided URL of the update webpage, which instructs the user to download and apply an update patch executable. The disassembly for this process can be seen in Figure 1, and the web page displayed to registered users can be seen in Figure 2. The web page for evaluation software users is similar except it doesn’t ask for email and password information.
If an attacker is able to intercept the initial UDP query and send back their own URL, then the user in the above scenario would be prompted to download and execute an attacker-controlled payload. Any executable downloaded and run in this way would execute with user privileges, though it could request elevation of privileges the same way the legitimate installer does.
Figure 2: Greyware’s update webpage
Technical analysis
Observing the weakness in the update protocol is straightforward. By viewing the traffic generated during the update check in a tool like Wireshark, we can see two UDP packets originating from the user software: one Domain Name System (DNS) query, and one packet sent to the IP resolved from the DNS query to UDP port 9909.
Figure 3: Client upgrade request packet contents
The upgrade request packet contains the client’s version string in ASCII in plaintext as shown in Figure 3.
Figure 4: Update server response to up-to-date clients
Figure 4 shows a normal response from the update server contains only the plaintext phrase “CURRENT”, demonstrating there was no encryption or authentication used.
Exploit
In order to demonstrate the weakness in this process, the provided script, upgrade_attack.py, listens on the provided network interface for upgrade traffic and responds to the appropriate DNS and Domain Time II requests. Additionally, the Proof of Concept (PoC) has an Hypertext Transfer Protocol (HTTP) impersonation mode (see --help). In this mode, the PoC will respond to HTTP requests as well, and direct users to a look-alike web server with the correct URL but over HTTP instead of HTTPS. When run outside of the HTTP impersonation mode, the PoC will send users directly to the IP of the web server. The script’s functionality can be summarized in how it deals with each of these three protocols:
Listens for and responds to DNS requests for update.greyware.com
Listens for and responds to unencrypted Domain Time II version check packets, providing a URL that the target will open via HTTP
Serves a lookalike update webpage over HTTP as well as a demonstration executable for users to download and run
The result is an attack that mirrors the appearance of the legitimate update mechanism in order to increase its believability (see Figure 5).
Figure 5: Greyware’s official update website (left) and the demonstration attack website (right)
The PoC itself was tested and verified to work against versions 4.1.b.20070308, 5.1.b.20100731, and 5.2.b.20210103 of Domain Time II.
Testing
To test the provided PoC, the easiest setup is to create a 64-bit Windows 10 Virtual Machine (VM) and install the evaluation version of Domain Time II (available here: https://www.greyware.com/software/domaintime/). Since both the client and server are vulnerable, you can choose to install either one. To simplify the setup, set the network adapter of the VM to NAT.
Once installed, return to your host and run the upgrade_attack.py script. You will need to provide the IP of your host (as visible to the client VM) and the name of the interface shared between the host and the guest VM. In our demonstration using VMWare, this is “vmnet8”.
python3 upgrade_attack.py vmnet8 XXX.XXX.XXX.XXX
Depending on your host configuration, you may need to run this script with root privileges. Once the script starts sniffing the specified interface for the target DNS request, trigger the update process from within the guest VM. In the Windows system tray (bottom right of the screen), right click the dttray.exe icon, select “Setup” then “Check for newer version now…” This will trigger the update process and start the MotS race. If the attack server wins the race, the following messages will appear in the console output of upgrade_attack.py:
DNS Query for "update.greyware.com." from <Guest VM IP>
[+] Target DNS Query responded to with <Host IP>
DNS Response for "update.greyware.com." from <Attack Server>
DT2 from <Guest VM IP>:60605 to <Host IP>:9909
[+] Responded to target DT2 Update request: <Payload>
DT2 from <Host IP>:9909 to <Guest VM IP>:60605
These messages indicate that the attack server sniffed the DNS request for the legitimate upgrade server, responded with its own IP, then responded to the upgrade request with its own payload. In this case, the payload is a fake website that mimics a legitimate Greyware Automation Products page. At the bottom of the page is a link to “Get the patch!” Clicking this link prompts the user to download a payload (calc.exe) and execute it as the current user.
We’ve chosen opening the calculator application as an easily-observed payload action, but the attack server is set up to transparently serve the attacker’s chosen executable while showing the user the executable name they requested (typically dtpatch.exe). The included demonstration payload illustrates what warnings the user would experience in an attack that isn’t trying to evade antivirus, but for testing purposes the payload could be replaced with Microsoft’s signed calc.exe or a penetration testing tool. Such testing will show the impact in payload choice on what the victim would see.
[embedded content]
Victim’s Perspective when running the PoC
Since the MotS vulnerability exploited by this PoC is a race (between the attack server and the legitimate DNS server), the PoC is not guaranteed to succeed every time. Additionally, the use of the HTTP impersonation mode introduces a second race that must be won for the PoC to be successful. If an attacker can achieve a MitM scenario on the traffic, they can ensure they always win the race by blocking either traffic to/from the Internet side. For testing purposes, we recommend simulating that scenario by disabling your host’s access to the internet and not running in HTTP impersonation mode.
Impact
The expected deployment scenario for this software is that the Domain Time II Server is installed on the Domain Controller within an Active Directory forest, and that the Update Server component would be run from such a machine (see “admin.txt” in the Domain Time II install bundle).
As such, the impact of successfully executing a MotS attack against a server would be to execute malware with administrative privileges in the context of the server. Since the Domain Time II server can track and update versions of the client software across the network, compromising the server could lead to attackers being able to spread laterally across a network to workstations, database servers, or source code repositories. All this could be performed under the guise of legitimate administration tasks of recognized software, similar to how some recent intrusions hid their activity on a network under the guise of Solar Winds software activity.
It is also possible that any user running the client software could infect themselves with malware, regardless of whether they are in a standalone client or domain setting, though in a domain setting the malware may be limited to domain user permissions.
Affected software
Since Domain Time II is closed-source software, it is difficult to generate an exact list of impacted versions. GRIMM was able to obtain evaluation copies of the following three versions of Domain Time II: 5.2.b.20210103, 5.1.b.20100731 (released in 2010), and 4.1.b.20070308 (released in 2007). Through static analysis of the software installed by these installers, GRIMM was able to confirm that the vulnerability exists in all three versions of Domain Time II. As such, it is reasonable to believe that the vulnerability affects all versions of Domain Time II released after 4.1.b20070308. It is possible that the vulnerability exists prior to this version, but GRIMM was unable to source earlier versions of the software. A fix for this vulnerability was released in version 5.2.b.20210331.
Conclusions
This blog post details a MotS attack that allows attackers to potentially gain code execution on machines running versions of Domain Time II that date back at least ten years. The crux of this vulnerability lies in the lack of authentication between Domain Time II servers and clients, and external Greyware update servers. If an attacker is able to detect outgoing update requests and respond to them before the legitimate Greyware servers do, then said attacker can direct users to download executable code from attacker-controlled servers. A combination of privilege reduction (e.g. only allowing Domain Time II servers to call out for external updates) and better user training (e.g. create documentation on secure update procedures) poses significant mitigation to this, and similar, vulnerabilities.
Timeline
03/30/2021 – Notified vendor
03/31/2021 – New version of software released with patch (5.2.b.20210331)
04/06/2021 – NotQuite0DayFriday release
04/06/2021 – Blog post release
GRIMM’s Private Vulnerability Disclosure (PVD) Program
GRIMM’s Private Vulnerability Disclosure (PVD) program is a subscription-based vulnerability intelligence feed. This high-impact feed serves as a direct pipeline from GRIMM’s vulnerability researchers to its subscribers, facilitating the delivery of actionable intelligence on 0-day threats as they are discovered by GRIMM. We created the PVD program to allow defenders to get ahead of the curve, rather than always having to react to events outside of their control.
The goal of this program is to provide value to subscribers in the following forms:
Advanced notice (at least two weeks) of 0-days prior to public disclosure. This affords subscribers time to get mitigations in place before the information is publicly available.
In-depth, technical documentation of each vulnerability.
PoC vulnerability exploitation code for:
Verifying specific configurations are vulnerable
Testing defenses to determine their effectiveness in practice
Training
Blue teams on writing robust mitigations and detections
Red teams on the art of exploitation
A list of any indicators of compromise
A list of actionable mitigations that can be put in place to reduce the risk associated with each vulnerability.
The research is done entirely by GRIMM, and the software and hardware selected by us is based on extensive threat modeling and our team’s deep background in reverse engineering and vulnerability research. Requests to look into specific software or hardware are welcome, however we can not guarantee the priority of such requests. In addition to publishing our research to subscribers, GRIMM also privately discloses each vulnerability to its corresponding vendor(s) in an effort to help patch the underlying issues.
If interested in getting more information about the PVD program, reach out to us.
Working with GRIMM
Want to join us and perform more analyses like this? We’re hiring. Need help finding or analyzing your bugs? Feel free to contact us.
Cybercriminals are increasingly leveraging fileless malware, cryptominers and encrypted attacks, targeting users both at remote locations as well as corporate assets behind the traditional network perimeter. These were among the findings of WatchGuard Technologies’ Internet Security Report for Q4 2020, which found fileless malware and cryptominer attack rates grew by nearly 900% and 25%, respectively,..
After a year of shifting to the cloud at a dizzying pace, it seems that trend shows no sign of slowing down. Organizations continue the shift to complex cloud environments, though many find providers’ native security controls fall short of their needs. More than half of the organizations surveyed for the State of Cloud Security..
Organizations are increasingly turning to containers to fuel their digital transformations. According to BMC, a 2019 survey found that more than 87% of respondents were running containers—up from 55% just two years earlier. Additionally, 90% of survey participants that were running applications in containers were doing so in production. That was up from 84% in […]… Read More
Be the first to post a comment regarding this story.