I think you're right. The other clean one is my vanity npub. I'll switch account right quick and make this same Death Metal post.
lol I think this is the clean one.
Thanks for the reminder. It's me, I'll log out of this one and into my other one. I didn't remember which one was compromised. I remember that day a few months ago...
Hi Nostr! What's new!?
Here are the images associated with pubkey nostr:npub1hn4zhxzsd5w4m5kvq326gqnsrc6zcakhparw8pee4tw7wlxw70ysawhtl5:
cool bot
China Has a Controversial Plan for Brain-Computer Interfaces
https://www.wired.com/story/china-brain-computer-interfaces-neuralink-neucyber-neurotech/
> At a tech forum in Beijing last week, a Chinese company unveiled a “homegrown” brain-computer interface that allowed a monkey to seemingly control a robotic arm just by thinking about it. In a video shown at the event, a monkey with its hands restrained uses the interface to move a robotic arm and grasp a strawberry. The system, developed by NeuCyber NeuroTech and the Chinese Institute for Brain Research, involves soft electrode filaments implanted in the brain, according to state-run news media outlet Xinhua. Researchers in the US have tested similar systems in paralyzed people to allow them to control robotic arms, but the demonstration underscores China’s progress in developing its own brain-computer interface technology and vying with the West. Brain-computer interfaces, or BCIs, collect and analyze brain signals, often to allow direct control of an external device, such as a robotic arm, keyboard, or smartphone. In the US, a cadre of startups, including Elon Musk’s Neuralink, are aiming to commercialize the technology.
Nearly 20% of Docker Hub Repositories Spread Malware & Phishing Scams
![Attack on Docker Hub](https://media.jfrog.com/wp-content/uploads/2024/04/30145652/Attack-on-Docker-Hub_863x300.png" class="embedded-image" loading="lazy">)
As key parts of the software ecosystem, and as partners, JFrog and Docker are working together to strengthen the software ecosystem. Part of this effort by JFrog’s security research team involves continuous monitoring of open-source software registries in order to proactively identify and address potential malware and vulnerability threats.
In former publications, we have discussed some of the malware packages we found on the [NPM](https://jfrog.com/blog/npm-manifest-confusion-six-months-later/), [PyPI](https://jfrog.com/blog/new-malware-targets-python-developers-uses-tor-for-c2-communication/) and [NuGet](https://jfrog.com/blog/attackers-are-starting-to-target-net-developers-with-malicious-code-nuget-packages/) registries by continuously scanning all major public repositories. In this blog post, **we reveal three large-scale malware campaigns we’ve recently discovered, targeting Docker Hub, that planted millions of “imageless” repositories with malicious metadata**. These are repositories that do not contain container images (and as such cannot be run in a Docker engine or Kubernetes cluster) but instead contain metadata that is malicious.
[Docker Hub](https://hub.docker.com/) is a platform that delivers many functionalities to developers, presenting numerous opportunities for development, collaboration, and distribution of Docker images. Currently, it is the number one container platform of choice for developers worldwide. It hosts over 15 million repositories.
Yet, a significant concern arises when considering the content of these public repositories. Our research reveals that nearly 20% of these public repositories (almost three million repositories!) actually hosted malicious content. The content ranged from simple spam that promotes pirated content, to extremely malicious entities such as malware and phishing sites, uploaded by automatically generated accounts.
![](https://media.jfrog.com/wp-content/uploads/2024/04/29173734/Img1.png" class="embedded-image" loading="lazy">)
While the Docker Hub maintainers currently moderate many of the uploaded repositories, and the repositories we found have been taken down after our disclosure, these attacks show that blocking 100% of malicious uploads is immensely challenging.
## What enabled this attack?
Docker Hub is Docker’s cloud-based registry service that hosts and distributes images. Its core concept is a repository, which includes text descriptions and metadata on top of the container data.
![Docker Hub’s library](https://media.jfrog.com/wp-content/uploads/2024/04/21123804/Image1_Docker-Hubs-library.png" class="embedded-image" loading="lazy">)_Docker Hub’s repository library (click to expand)_
While the core feature of a Docker repository is to hold a collection of Docker **images** (an application that can be updated and accessible through a fixed name), Docker Hub introduces several key enhancements. The most significant of them is community features.
For public repositories, Docker Hub acts as a community platform. It allows users to search and discover images that might be useful for their projects. Users can also rate and comment on repositories, helping others gauge the reliability and utility of available images.
To help users search and use images, **Docker Hub allows repository maintainers to add short descriptions and documentation in HTML format**, which will be displayed on the repository’s main page. Usually, repository documentation aims to explain the purpose of the image and provide guidelines for its usage.
![Example of a Legitimate Repository’s Documentation](https://media.jfrog.com/wp-content/uploads/2024/04/21123953/Image2_Example-of-a-Legitimate-Repositorys-Documentation.png" class="embedded-image" loading="lazy">)_Example of a Legitimate Repository’s Documentation_
But as Murphy’s law for security says, if something can be exploited by malware developers, it inevitably will be.
JFrog’s security research team discovered that ~4.6 million of the repositories in Docker Hub are imageless and have no content except for the repository’s documentation. A deeper inspection revealed that **the vast majority of these imageless repositories were uploaded with a malicious endgame** – their overview page tries to deceive users into visiting phishing websites or websites that host dangerous malware.
Before discussing the various malicious payloads, we will explain our methodology for finding these malicious repositories.
## Identifying the malicious repositories
We started our research by identifying anomalies in the publication patterns of Docker Hub repositories. To achieve this, we pulled all “imageless” Docker Hub repositories published in the past five years, grouped them by creation date, and plotted them on a graph:
![](https://media.jfrog.com/wp-content/uploads/2024/04/29173931/Img2.png" class="embedded-image" loading="lazy">)_Graph of Monthly Created Repositories_
As we can see, the usual activity on Docker Hub is quite linear, but we can see a few spikes in 2021 and 2023. If we zoom in, we see that the daily activity is well-defined and follows a working week pattern. Even visually, we can notice a working week pattern: more repositories are created on work days and fewer on weekends.
![](https://media.jfrog.com/wp-content/uploads/2024/04/29174340/Img3.png" class="embedded-image" loading="lazy">)_Zooming in on the 2023 anomaly_
The graph shows that when the unusual activity starts, **the number of daily-created repositories multiplies tenfold**.
We thoroughly analyzed the repositories created on days with anomalies and found many repositories deviated from the norm. The main deviation is that they didn’t contain container images, just a documentation page, making the repository unusable, as it can’t be pulled and run as a normal docker image.
![Example of a Malicious Repository](https://media.jfrog.com/wp-content/uploads/2024/04/21124325/Image3_Example-of-a-Malicious-Repository.png" class="embedded-image" loading="lazy">)_Example of a Malicious Repository_
For instance, the repository shown in the screenshot above contains a few links in the description directing users to a phishing website: https\[://\]www\[.\*\*\*\*\*\*medz\*\*\*\*\*.\]com. This site deceives unsuspecting visitors by promising to purchase prescription-only medications but then stealing their credit card details.
While all anomalous repositories were somewhat different from each other and were published by various users, most followed the same patterns. That allowed us to create a signature and group them by families (or campaigns). Once we applied this signature to all imageless repositories, we gathered a list of the hub users publishing them. We classified all repositories published by these users as malware as well.
After we plotted the campaigns on the timeline, we got an understanding of the periods when the largest malware campaigns operated.
Two were most active in the first half of 2021, publishing thousands of repositories daily. The downloader campaign made one more attempt in August 2023. The “Website SEO” campaign operated differently, consistently pushing a small number of repositories daily over three years.
![](https://media.jfrog.com/wp-content/uploads/2024/04/29174638/Img4.png" class="embedded-image" loading="lazy">)_Malware Repositories Registered Per Day by Campaign_
At the time of DockerCon 2023, [Docker Hub contained 15 million repositories](https://www.docker.com/blog/docker-11-year-anniversary/), so we will use this number as reference for the total Docker Hub repository count.
The total number of imageless repositories published to Docker Hub is 4.6M – 30% of all public repositories. **We were able to link 2.81M (~19%) of these repositories to these large malicious campaigns**.
In addition to the large campaigns we identified, our analysis also revealed the presence of smaller sets of repositories. These campaigns seemed mostly focused on spam / SEO, however we could not classify all of the variants of these campaigns. These smaller “campaigns” contained less than 1000 packages each. For our categorization, we allocated these smaller sets to a group labeled “Other suspicious” –
_![](https://media.jfrog.com/wp-content/uploads/2024/04/30033900/Img5-1-1.png" class="embedded-image" loading="lazy">)DockerHub repositories classification_
Distribution of malicious repositories by campaigns:
| | | |
| --- | --- | --- |
| **Campaign** | **\# of Repositories (% of all DH Repositories)** | **\# of Users** |
| Website SEO | 215451 (1.4%) | 194699 |
| Downloader | 1453228 (9.7%) | 9309 |
| eBook Phishing | 1069160 (7.1%) | 1042 |
| Other suspicious imageless | 76025 (0.5%) | 3689 |
| **Total** | **2.81M (18.7%)** | **208739** |
We can see different approaches in the distribution of the malicious repositories. While the “Downloader” and “eBook Phishing” campaigns create fake repositories in batches over a short time period, the “Website SEO” campaign creates a few repositories daily over the whole time frame and uses a single user per repository.
Now that we know which main malware campaigns were running on Docker Hub, let’s review their tactics and techniques in depth.
1. [“Downloader” Campaign](#downloader-campaign)
2. [“eBook Phishing” Campaign](#ebook-phishing)
3. [“Website SEO” Campaign](#website-seo)
## Analysis of the Docker Hub malware campaigns
### 1\. “Downloader” Campaign
![](https://media.jfrog.com/wp-content/uploads/2024/04/29174853/Img6.png" class="embedded-image" loading="lazy">)_Distribution of the Downloader Campaign’s Repositories_
Repositories belonging to this campaign contain automatically generated texts with SEO text proposing to download pirated content or cheats for video games. Additionally, the text includes a link to the alleged advertised software.
This campaign operated in **two distinct rounds** (circa 2021 and 2023), while both rounds used exactly the same malicious payload (see analysis further down).
![Truck Simulator APK Para](https://media.jfrog.com/wp-content/uploads/2024/04/21125145/Image4_Truck-Simulator-APK-Para.png" class="embedded-image" loading="lazy">)
_Example of a malicious repository with a malware download link_
#### The 2021 round – Malicious domains pretending to be URL shorteners
Most URLs used in the campaign pretend to use known URL shorteners (ex. tinyurl.com), similar to [an attack campaign on Google Ads](https://asec.ahnlab.com/en/22636/) found in 2021 as well. After we tried to resolve them, we discovered that, unlike the real shorteners, these malicious shorteners don’t actually encode the URL. Instead, **they encode a file name** and resolve a link to a different domain each time a malicious resource is shut down.
For instance, during our investigation, the URL **blltly\[.\]com/1w1w1** redirected to **https\[://\]failhostingpolp\[.\]ru/9ebeb1ba574fb8e786200c62159e77d15UtXt7/x60VKb8hl1YelOv1c5X1c0BuVzmFZ8-teb-LRH8w**. However, subsequent requests to the server triggered the generation of a new URL path each time.
Their sole purpose is to serve as a proxy for a malicious CDN.
Every subsequent request to the same shortened link brings a different URL, and if the server that’s hosting malicious files is shut down, the shortener will return a link to a new, active one.
We gathered a list of all malicious domains and compiled a table showing the correspondence between the fraudulent shorteners and their real, trustworthy versions.
| | |
| --- | --- |
| **Malware shortener** | **Impersonated legitimate shortener** |
| blltly\[.\]com
bltlly\[.\]com
byltly\[.\]com
bytlly\[.\]com | https://bitly.com/ |
| tinourl\[.\]com
tinurli\[.\]com
tinurll\[.\]com
tiurll\[.\]com
tlniurl\[.\]com | https://tinyurl.com |
| urlca\[.\]com
urlcod\[.\]com
urlgoal\[.\]com
urllie\[.\]com
urllio\[.\]com
urloso\[.\]com
urluso\[.\]com
urluss\[.\]com | https://urlgo.in/ |
| imgfil\[.\]com | https://imgflip.com/ |
| cinurl\[.\]com
fancli\[.\]com
geags\[.\]com
gohhs\[.\]com
jinyurl\[.\]com
miimms\[.\]com
picfs\[.\]com
shoxet\[.\]com
shurll\[.\]com
ssurll\[.\]com
tweeat\[.\]com
vittuv\[.\]com | |
_Fake URL Shorteners Used by the Malware Campaign_
This strategy, developed in 2021, worked for some time until AV companies found a list of the links and added them to their blacklists. Currently, browsers and providers raise alerts when an attempt is made to access one of the links from the table above.
#### The 2023 round – Enhanced anti-detection techniques
The second round of the campaign, which occurred in 2023, focused on avoiding detection. The malicious repositories no longer use direct links to malicious sources. Instead, they point to legitimate resources as redirects to malicious sources.
Among these resources is a page hosted on blogger.com that contains JavaScript code that redirects to the malicious payload after 500 milliseconds:
```
```
Another approach is a [well-known](https://isc.sans.edu/diary/How+Malware+Campaigns+Employ+Google+Redirects+and+Analytics/19843) open redirect bug in Google, which allows malicious actors to redirect users to a malicious site with a legitimate Google link using specific parameters.
Normally, the Google link **https://www\[.\]google\[.\]com/url?q=https%3A%2F%2Fexample.us%2F** doesn’t redirect a user to the target site. Instead, it shows a notice warning that they are being redirected to another domain.
![Redirect Notice](https://media.jfrog.com/wp-content/uploads/2024/04/21130320/Image5_Redirect-Notice.png" class="embedded-image" loading="lazy">)_Example of a Redirection Notice_
However, it’s possible to add the undocumented parameter **usg** to disable this warning. The parameter contains a hash or signature that causes google.com to redirect to the target site automatically –
**PROTOCOL:**https**HOST:**www.google.com**PATH:**/url**PARAMS:**
| | | |
| --- | --- | --- |
| **q** | \= | https://urlin.us/2vwNSW |
| **sa** | \= | D |
| **sntz** | \= | 1 |
| **usg** | \= | AOvVaw1A6cBKittNvLawLc7IB9M0 |
This redirect leads to the target site. At the time of writing, the target sites were gts794\[.\]com and failhostingpolp\[.\]ru. These sites lure the victim to download an advertised software. However, regardless of the name on the landing page, the downloaded file is always the same archive with an EXE installer. As we can see in the [AnyRun analysis](https://app.any.run/tasks/0d2a678c-4678-42ae-b824-e9e74adde227/), the malware installs a binary called **freehtmlvalidator.exe** into the directory “%LOCALAPPDATA%\\HTML Free Validator”
![Malicious Payload Served in the Downloader Campaign](https://media.jfrog.com/wp-content/uploads/2024/04/21131632/Image6_Malicious-Payload-Served-in-the-Downloader-Campaign.png" class="embedded-image" loading="lazy">)_Malicious Payload Served in the Downloader Campaign_
#### Analysis of the “Downloader” campaign payload
The payload of the “Downloader” campaign is a malicious executable that most antivirus engines detect as a generic Trojan.
![Security Vendor Analysis](https://media.jfrog.com/wp-content/uploads/2024/04/21131829/Image7_Security-Vendor-Analysis.png" class="embedded-image" loading="lazy">)_Detection of the Served Payload by Antiviruses_
The malware is written with the successor to the once-popular Delphi environment: Embarcadero RAD Studio 27.0.
The malware communicates with the C2C server **http://soneservice\[.\]shop/new/net\_api** using HTTP POST requests. The request is a JSON message XORed with the three-byte key “787” and encoded in hex.
```
{
"5E4B1B4F": "4D571F435C025E5B0A465B114B4602455C0F4B460A",
"465B0F": "664eed76ed570dbb4cba2bdcb3479b5f",
"4E531F4B": "en"
}
```
The fields of the JSON are encoded in the same manner but using a different key: “**\*2k**”. Knowing this, we can decode the request to
```
{
"type": "getinitializationdata",
"lid": "664eed76ed570dbb4cba2bdcb3479b5f",
"data": "en"
}
```
The first command sent by the malware to the server is **getinitializationdata**. It contains two parameters: the malware’s unique identifier (“lid”) and the system locale identifier. The latter informs the server about the language setting of the infected system, enabling customized responses. The malware uses this unique identifier for all subsequent server requests.
In response, the server provides layout and localization details specific to Delphi, which are adapted based on the system’s language setting.
Afterwards, the malware sends an **initialization** request passing information about the infected system. The information includes OS-specific information, hardware, installed browser, version of the .NET framework, running processes, and available network adapters. The server, in return, provides a link to the alleged promised software and a list of offers. The promised software part is represented by URL and file name:
```
"file": {
"download_url": "http:\/\/totrakto.com\/CRACK-IDA-Pro-V6-8-150423-And-HEX-Rays-Decompiler-ARM-X86-X64-iDAPROl.zip",
"name": "CRACK-IDA-Pro-V6-8-150423-And-HEX-Rays-Decompiler-ARM-X86-X64-iDAPROl.zip",
"size": 64918480
},
```
![](https://media.jfrog.com/wp-content/uploads/2024/04/29175144/Img7.png" class="embedded-image" loading="lazy">)_Malware’s Communication with the C2 Server_
The “offers” section of the response contains a list of the links to executables, too. Additionally, it outlines various conditions that must be met to drop executables. The most significant conditions are:
* **excludeGeoTargeting** contains codes of countries where the malware shouldn’t be installed
```
"excludeGeoTargeting": [
"RU",
"AZ",
"AM",
"BY",
]
```
* **blackAvList** contains a list of antivirus applications that will also prevent the malware from being installed
```
"blackAvList": [
"avast",
"avg",
"avira",
"nod32",
"mcafeeep",
"windef",
]
```
* A process blacklist (wasn’t observed in payload sample)
* A list of Windows registry entries that must be present on the target system (wasn’t observed in payload sample)
Considering that the malware already sends information about the system to the server, we find these conditions on the client a bit redundant. Also, the response contains fields that were never used by the malware binary but are typical for advertisement networks, such as **price, offer\_id**, and **advertiser\_id**. From these fields we can assume that this malware operation is part of a broader ecosystem, potentially involving adware or monetization schemes that benefit from the distribution and installation of third-party software. Building on this understanding, we further assume that these request parameters are likely copied and embedded into the software from a dubious advertising network API, where third parties may pay for the distribution of their executables.
```
"advertiser_id": 7,
"groupOffer_id": 43,
"price": 0.064,
"price_usd": 0.064,
"tarif": 0.08,
"use_balance": "0",
```
After processing the response, the malware shows an installation dialog that proposes to the user to download and install the software promised in the malicious Docker Hub repository –
![Download Assistant](https://media.jfrog.com/wp-content/uploads/2024/04/21133848/Image8_Download-Assistant.png" class="embedded-image" loading="lazy">)_Installation Dialog Shown by Malware_
After accepting, in addition to installing the promised software, the malware just downloads all the malicious binaries from offer and schedules their persistent execution with the command **“SCHTASKS.exe /Create /TN
### 2\. “eBook Phishing” Campaign
![](https://media.jfrog.com/wp-content/uploads/2024/04/29175243/Img8.png" class="embedded-image" loading="lazy">)_Malware repositories registered per day by ebook\_phishing campaign_
Nearly a million repositories created in the middle of 2021 turned Docker Hub into a “pirated eBook library”. These spam repositories all offered free eBook downloads containing randomly generated descriptions and download URLs –
![img. example of the phishing ebook repository](https://media.jfrog.com/wp-content/uploads/2024/04/21150009/Image9_img-example-of-the-phishing-ebook-repository.png" class="embedded-image" loading="lazy">)_Example of an eBook phishing repository_
All links eventually redirect the user to the same page: **http://rd\[.\]lesac\[.\]ru/**.
![ebook downloading landing page](https://media.jfrog.com/wp-content/uploads/2024/04/21150108/Image10_ebook-downloading-landing-page.png" class="embedded-image" loading="lazy">)_eBook download landing page_
After promising a free full version of the eBook, the website chooses a random page from the set available for the user’s IP and redirects them there. The following steps depend on the user’s country, but usually, it’s a form asking the user to enter credit card information.
Undoubtedly, the sole intent behind this action is phishing, aiming to steal credit card details and unknowingly enroll the user in a subscription service. The footer on these target sites usually has barely-readable text, saying the subscription charges 40-60€ per month.
![](https://media.jfrog.com/wp-content/uploads/2024/04/29175348/Img9.png" class="embedded-image" loading="lazy">)
![Some phishing sites from the campaign](https://media.jfrog.com/wp-content/uploads/2024/04/21150303/Image11_Some-phishing-sites-from-the-campaign.png" class="embedded-image" loading="lazy">)![Some phishing sites from the campaign](
https://media.jfrog.com/wp-content/uploads/2024/04/21150333/Image12_Some-phishing-sites-from-the-campaign.png" class="embedded-image" loading="lazy">)
_Some phishing sites from the campaign (click to expand)_
### 3\. “Website SEO” Campaign
Unlike the previous two campaigns, which were blatantly malicious (phishing / malware download) the aim of this campaign is not so clear. While the repositories themselves were obviously not uploaded in good faith, the content is mostly harmless – just a random description string with a username generated by the pattern “axaaaaaxxx” where a is a letter and x is a digit. All repositories published by these users have the same name: website.
**It is possible that the campaign was used as some sort of a stress test before enacting the truly malicious campaigns.**
This campaign also has a different registration routine. As we can see from the graph, the actors behind this campaign created a thousand repositories daily across three years! This is unlike the previous campaigns, which focused on generating imageless repositories in a much shorter time. In this campaign the attackers published only one repository per created user, whereas in the previous campaigns, a single user was used to publish thousands of repositories.
![](https://media.jfrog.com/wp-content/uploads/2024/04/29175607/Img10.png" class="embedded-image" loading="lazy">)_Malware repositories registered per day by “Website SEO” campaign_
In this campaign, the repository description usually contains a short, seemingly random, and senseless phrase without any other information.
Some of the repositories contain links to social network sites, but these seem to contain mostly garbage as well, and not malicious URLs or files –
![Repositories containing links to social network sites](https://media.jfrog.com/wp-content/uploads/2024/04/21150903/Image13_repositories-contain-links-to-social-network-sites.png" class="embedded-image" loading="lazy">)
![Repositories containing links to social network sites](https://media.jfrog.com/wp-content/uploads/2024/04/21150938/Image14_repositories-contain-links-to-social-network-sites.png" class="embedded-image" loading="lazy">)_Example of a Website SEO Campaign Repositories’ Description_
Below are some user names from this campaign, with the relevant descriptions in the repository documentation –
![User names with the relevant descriptions in the repository documentation](https://media.jfrog.com/wp-content/uploads/2024/04/21151115/Image15_user-names-with-the-relevant-descriptions-in-the-repository-documentation.png" class="embedded-image" loading="lazy">)_Random Phrases from the Website SEO Campaign’s Repositories_
When we searched for these usernames, we found that this campaign also targeted other platforms that have open contribution policies –
![Campaign targeting platforms that have a loose content moderation policy](https://media.jfrog.com/wp-content/uploads/2024/04/21151317/Image16_Campaign-targeting-platforms-that-have-a-loose-content-moderation-policy.png" class="embedded-image" loading="lazy">)_Website SEO Campaign Usernames Used in other Platforms_
## Disclosure to Docker Inc.
Prior to this publication, the JFrog research team disclosed all findings to the Docker security team, including 3.2M repositories that were suspected as hosting malicious or unwanted content. The Docker security team quickly removed all of the malicious and unwanted repositories from Docker Hub. We would like to thank the Docker security team for handling this disclosure quickly and professionally, and are happy to contribute to the continued safe use of the Docker ecosystem.
## How Can Docker Hub Users Avoid Similar Attacks?
Users should prefer using Docker images that are marked in Docker Hub as “Trusted Content” –
![](https://media.jfrog.com/wp-content/uploads/2024/04/30145322/img1-1.png" class="embedded-image" loading="lazy">)
Docker Hub has designated tags for trusted content that users can look for when browsing an image’s description page. The first tag is the [Docker Official Image](https://docs.docker.com/trusted-content/official-images/) tag, otherwise known as Docker Hub’s Library, a set of curated Docker repositories. The Library consists of repositories that are maintained by trusted and well-known software development foundations, organizations and companies, such as Python, Ubuntu and Node. The second tag is the [Verified Publisher](https://docs.docker.com/trusted-content/dvp-program/) tag, which is assigned to every repository that is part of the Docker Verified Publisher Program. This set contains repositories from commercial publishers, who have been verified by Docker Hub. And lastly, the [Sponsored OSS](https://docs.docker.com/trusted-content/dsos-program/) tag, which is assigned to repositories of open source projects that are sponsored by Docker Hub.
When browsing a repository’s page, a badge that indicates that the repository is part of one of the aforementioned types would appear next to the repository’s name, at the top of the page –
![](https://media.jfrog.com/wp-content/uploads/2024/04/30145407/img2-1.png" class="embedded-image" loading="lazy">)
Following these guidelines would decrease the risk of being manipulated into following a malicious link outside of Docker Hub from a repository’s description page. For example – none of the malicious repositories mentioned in this blog was marked as “Trusted Content”.
## Summary
Unlike typical attacks targeting developers and organizations directly, the attackers in this case tried to leverage Docker Hub’s platform credibility, making it more difficult to identify the phishing and malware installation attempts.
Almost three million malicious repositories, some of them active for over three years highlight the attackers’ continued misuse of the Docker Hub platform and the need for constant moderation on such platforms.
## IoCs
failhostingpolp\[.\]ru
gts794\[.\]com
blltly\[.\]com
ltlly\[.\]com
byltly\[.\]com
bytlly\[.\]com
cinurl\[.\]com
fancli\[.\]com
geags\[.\]com
gohhs\[.\]com
imgfil\[.\]com
jinyurl\[.\]com
miimms\[.\]com
picfs\[.\]com
shoxet\[.\]com
shurll\[.\]com
ssurll\[.\]com
tinourl\[.\]com
tinurli\[.\]com
tinurll\[.\]com
tiurll\[.\]com
tlniurl\[.\]com
tweeat\[.\]com
urlca\[.\]com
urlcod\[.\]com
urlgoal\[.\]com
urllie\[.\]com
urllio\[.\]com
urloso\[.\]com
urluso\[.\]com
urluss\[.\]com
vittuv\[.\]com
rd\[.\]lesac\[.\]ru
soneservice\[.\]shop
The little-known Soviet mission to rescue a dead space station (2014)
The following story happened in 1985 but subsequently vanished into obscurity. Over the years, many details have been twisted, others created. Even the original storytellers got some things just plain wrong. After extensive research, writer Nickolai Belakovski is able to present, for the first time to an English-speaking audience, the complete story of Soyuz T-13’s mission to save Salyut 7, a fascinating piece of in-space repair history.
It’s getting dark, and Vladimir Dzhanibekov is cold. He has a flashlight, but no gloves. Gloves make it difficult to work, and he needs to work quickly. His hands are freezing, but it doesn’t matter. His crew’s water supplies are limited, and if they don’t fix the station in time to thaw out its water supply, they’ll have to abandon it and go home, but the station is too important to let that happen. Quickly, the sun sets. Working with the flashlight by himself is cumbersome, so Dzhanibekov returns to the ship that brought them to the station to warm up and wait for the station to complete its pass around the night side of the Earth. \[1\]
He’s trying to rescue Salyut 7, the latest in a series of troubled yet increasingly successful Soviet space stations. Its predecessor, Salyut 6, finally returned the title of longest manned space mission to the Soviets, breaking the 84-day record set by Americans on Skylab in 1974 by 10 days. A later mission extended that record to 185 days. After Salyut 7’s launch into orbit in April 1982, the first mission to the new station further extended that record to 211 days. The station was enjoying a relatively trouble-free start to life. \[4\]
However, this was not to last. On February 11, 1985, while Salyut 7 was in orbit on autopilot awaiting its next crew, mission control (TsUP) noticed something was off. Station telemetry reported that there had been a surge of current in the electrical system, which led to the tripping of overcurrent protection and the shutdown of the primary radio transmitter circuits. The backup radio transmitters had been automatically activated, and as such there was no immediate threat to the station. Mission controllers, very tired now that the end of their 24-hour shift was approaching, made a note to call specialists from the design bureaus for the radio and electrical systems. The specialists would analyze the situation, and produce a report and recommendation, but for now the station was fine, and the next shift was ready to come on duty.\[9\]
Without waiting for the specialists to arrive, or perhaps not bothering to call them in the first place, the controllers on the next shift decided to reactivate the primary radio transmitter. Perhaps the overcurrent protection had been tripped accidentally, and if not, then it should still be functional and should still activate if there really was a problem. The controllers, acting against established tradition and procedures of their office, sent the command to reactivate the primary radio transmitter. Instantly, a cascade of electrical shorts swept through the station, and knocked out not only the radio transmitters, but also the receivers. At 1:20pm and 51 seconds on February 11, 1985, Salyut 7 fell silent and unresponsive. \[8\]\[9\]
## What do we do now?
The situation put flight controllers in an uncomfortable position. One option available to them was to simply abandon Salyut 7 and wait for its successor, Mir, to become available before continuing the manned space program. Mir was on schedule to be launched within one year, but waiting for Mir to become available would not only mean suspending the space program for a year; it also meant that a significant amount of scientific work and engineering tests planned for Salyut 7 would have to go undone. Moreover, admitting defeat would be an embarrassment for the Soviet space program, particularly painful considering the multitude of previous failures in the Salyut series as well as the apparent successes the Americans were enjoying with the Space Shuttle. \[9\]
There was only one other option: fly a repair crew to the station to fix it from the inside, manually. But this could easily become yet another failure. The standard procedures for docking to a space station were entirely automated and relied heavily on information from the station itself about its precise orbital and spatial coordinates. During those rare occurrences when the automated system failed and a manual approach was required, the failures were all within several hundred meters of the station. How does one approach a silent space station? \[9\] The lack of communication presented another problem: there was no way to know the status of the onboard systems. While the station was designed to fly autonomously, the automated systems could only cope with so many failures before human intervention would be required. The station could be fine upon the repair crew's arrival, requiring no more repair work than replacing the damaged transmitters, or there could have been a fire on the station, or it could have depressurized from having been struck by space debris, etc.; there would be no way to know.\[3\]
If there was a meeting in which top managers discussed and weighed all the options, the notes of that meeting have not been made public. What \*is\* known, however, is that the Soviets decided to attempt a repair mission. This would mean rewriting the book on docking procedures from scratch and hoping that nothing else went wrong aboard the station while communication was down, because if something else did go wrong, the repair crew might not be able to handle it. It was a bold move.
## “Docking with a non-cooperative object”
The first order of business for the repair mission was figuring out how they would get to the station. For an approach to the station under better circumstances, the Soyuz (a 3-seat ship used to ferry cosmonauts to and from space stations) would receive information from the station via mission control (TsUP) as soon as it reached orbit, long before the station would be visible to the crew. This communication would contain information about the orbit of the space station so that the visiting craft could plot a rendezvous orbit. Once the two craft were 20-25km apart, a direct line of communication would be established between the station and the ship, and the automated system would bring the two craft together and complete the docking.\[3\]
)
Part 1: A depiction of a typical Soyuz rendezvous and docking. Part 2: A depiction of the modified rendezvous and docking procedure employed for Soyuz T-13. Notice how in parts 2b and 2c the ship is actually flying sideways.
[epizodsspace.noip.org (translated by the author)](http://epizodsspace.no-ip.org/bibl/n_i_j/1985/11/letopis.html.)
Although all Soyuz pilots were trained to perform a manual docking, it was rare for the automated system to fail. Of those rare failures, the worst was in June 1982 on Soyuz T-6 when a computer failure stopped the automated docking process 900m away from the station. Vladimir Dzhanibekov immediately took over controls and successfully docked his Soyuz with Salyut 7 a full 14 minutes ahead of schedule \[4\]. Naturally, Dzhanibekov was the leading candidate to pilot any proposed mission to rescue Salyut 7.
An entirely new set of docking techniques had to be developed, and this was done under a project titled “docking with a non-cooperative object.” \[5\] The station’s orbit would be measured using ground-based radar, and this information would be communicated to the Soyuz, which would then plot a rendezvous course. The goal was to get the ship within 5km of the station, from which point it was deemed a manual docking was technically possible. \[3\] The conclusion of those responsible for developing these new techniques were that the odds of mission success were 70 to 80 percent, after proper modifications to the Soyuz. \[2\],\[3\] The Soviet government accepted the risk, deeming the station too valuable to simply let it fall from orbit uncontrolled.
Modifications to the Soyuz began. The automated docking system would be removed entirely, and a laser rangefinder installed in the cockpit to assist the crew in determining their distance and approach rate. The crew would also bring night vision goggles in case they had to dock with the station on the night side. The third seat of the ship was removed, and extra supplies, like food and, as would later prove critical, water, were brought on board. The weight saved by the removal of the automatic system and the third chair were used to fill the propellant tanks to their maximum possible level. \[1\],\[3\],\[11\]
## Who would fly the mission?
When it came to selecting a flight crew, two things were very important. First of all, the pilot should have had experience performing a manual docking in orbit, not just in simulators, and secondly, the flight engineer would need to be very familiar with Salyut 7’s systems. Only three cosmonauts had completed a manual docking in orbit. Leonid Kizim, Yuri Malyshev, and Vladimir Dzhanibekov. Kizim had only recently returned from a long duration mission to Salyut 7, and was still undergoing rehabilitation from his spaceflight, which ruled him out as a possible candidate. Malyshev had limited spaceflight experience, and had not trained for Extra-Vehicular Activity (EVA, or spacewalk), which would be required later in the mission to augment the station’s solar panels, provided the rehabilitation of the space station went well.\[1\]
This left Dzhanibekov, who had flown in space four times for a week or two each time, but had trained for long duration missions and for EVA. However, he was restricted from long duration flight by the medical community. Being at the top of the short list for mission commander, Dzhanibekov was quickly placed into the care of physicians who, after several weeks of medical tests and evaluation, cleared him for a flight lasting no more than 100 days. \[1\]
To fulfill the role of flight engineer the list was even shorter: just one person. Victor Savinikh had flown once before, on a 74 day mission to Salyut 6. During that mission he played host to Dzhanibekov and Mongolia’s first cosmonaut as they visited the station on Soyuz 39. Moreover, he was already in the process of training for the next long-duration mission to Salyut 7, which had been scheduled to launch on May 15, 1985. \[1\]
By the middle of March, the crew had been firmly decided. Vladimir Dzhanibekov and Victor Savinikh were chosen to attempt one of the boldest, most complicated in-space repair efforts to date. \[1\]
## Po’yehali! Let’s go!
)
Salyut 7 as seen from the approaching Soyuz T-13 crew. Notice how the solar panels are slightly askew.
[Wikimedia](
)
On June 6, 1985, nearly four months after contact with the station had been lost, Soyuz T-13 launched with Vladimir Dzhanibekov as commander and Victor Savinikh as flight engineer. \[1\],\[6\] After two days of flight, the station came into view.
As they approached the station, live video from their ship was being transmitted to ground controllers. To the right is one of the images controllers saw.
The controllers noticed something very wrong: the station’s solar arrays weren’t parallel. This indicated a serious failure in the system which orients the solar panels toward the sun, and immediately led to concerns about the entire electrical system of the station. \[1\]
The crew continued their approach.
> **Dzhanibekov:** “Distance, 200 meters. Engaging engines. Approaching the station at 1.5 m/s, rotational speed of the station is normal, it’s practically stable. We’re holding, and beginning our turn. Oh, the sun is in a bad spot now… there, that’s better. Docking targets aligned. Offset between the ship and the station within normal parameters. Slowing down… waiting for contact.”
Silently, slowly, the crew’s Soyuz flew toward the forward docking port of the station.
> **Savinikh:** “We have contact. We have mechanical capture.”
The successful docking to the station was a great victory, and demonstrated for the first time in history that it was possible to rendezvous and dock with virtually any object in space, but it was early to celebrate. The crew received no acknowledgement, either electrical or physical, from the station of their docking. One of the main fears about the mission, that something else would go seriously wrong while the station was out of contact, was quickly becoming a reality.
A lack of information on the crew’s screens about the pressure inside the station led to concerns that the station had de-pressurized, but the crew pressed ahead, carefully. Their first step would be to try to equalize the pressure between the ship and the station, if possible. \[1\]\[3\]
Webb captures iconic Horsehead Nebula in unprecedented detail
# Webb captures iconic Horsehead Nebula in unprecedented detail
The NASA/ESA/CSA James Webb Space Telescope has captured the sharpest infrared images to date of one of the most distinctive objects in our skies, the Horsehead Nebula. These observations show a part of the iconic nebula in a whole new light, capturing its complexity with unprecedented spatial resolution.
)
Webb’s new images show part of the sky in the constellation Orion (The Hunter), in the western side of the Orion B molecular cloud. Rising from turbulent waves of dust and gas is the Horsehead Nebula, otherwise known as Barnard 33, which resides roughly 1300 light-years away. The nebula formed from a collapsing interstellar cloud of material, and glows because it is illuminated by a nearby hot star. The gas clouds surrounding the Horsehead have already dissipated, but the jutting pillar is made of thick clumps of material that is harder to erode. Astronomers estimate that the Horsehead has about five million years left before it too disintegrates. Webb’s new view focuses on the illuminated edge of the top of the nebula’s distinctive dust and gas structure.
[Zoom into the Horsehead Nebula](https://www.esa.int/ESA_Multimedia/Videos/2024/04/Zoom_into_the_Horsehead_Nebula)
)
The Horsehead Nebula is a well-known photon-dominated region, or PDR. In such a region ultraviolet light from young, massive stars creates a mostly neutral, warm area of gas and dust between the fully ionised gas surrounding the massive stars and the clouds in which they are born. This ultraviolet radiation strongly influences the gas chemistry of these regions and acts as the most important source of heat.
)
Thanks to Webb’s MIRI and NIRCam instruments, an international team of astronomers have revealed for the first time the small-scale structures of the illuminated edge of the Horsehead. They have also detected a network of striated features extending perpendicular to the PDR front and containing dust particles and ionised gas entrained in the photo-evaporative flow of the nebula. The observations have also allowed astronomers to investigate the effects of dust attenuation and emission, and to better understand the multidimensional shape of the nebula.
A leadership crisis in the Nix community
https://lwn.net/SubscriberLink/970824/0d89c6d83efad1e0/
By **Daroc Alden**
April 29, 2024
On April 21, a group of anonymous authors and non-anonymous signatories published [a lengthy open letter](https://save-nix-together.org/) to the [Nix](https://nixos.org/) community and Nix founder Eelco Dolstra calling for his resignation from the project. They claimed ongoing problems with the project's leadership, primarily focusing on the way his actions have allegedly undermined people nominally empowered to perform various moderation and governance tasks. Since its release, the letter has gained more than 100 signatures.
#### Decision-making authority
The Nix project is governed by the [NixOS Foundation](https://github.com/NixOS/foundation), a non-profit organization that handles the project's finances and legal responsibilities. The foundation itself is headed by a board with five voting members, chaired by Dolstra. There are no term limits, and the board selects its own membership and chair. According to [the board's team page](https://nixos.org/community/teams/foundation-board/), its responsibilities include handling "administrative, legal, and financial tasks", sponsorships and donations, funding for "community events and efforts", and acting as an arbiter in case of conflicts in the community. Notably, the board "is not responsible for technical leadership, decisions, or direction", nor is it expected to handle all decision making. The board is responsible for providing "a framework for teams to self-organize", including a duty to "[h]and out the credentials and permissions required for the teams' work".
The open letter has several related complaints, but the most central one is that they allege Dolstra has repeatedly strong-armed the board and members of other community teams to overrule their decisions:
> For example, after months of discussion on sponsorship policy in the board, with consensus having been formed on a policy that allows community veto of NixCon sponsors, Eelco (and Graham [Christensen], at the same time) appeared at the [open board call over 45 minutes in](https://discourse.nixos.org/t/open-board-call-2024-03-20/41898/), and began re-litigating the issue of whether we need to limit sponsorship to begin with, which had already been agreed upon by everyone but him.
Christensen is Dolstra's co-founder at [Determinate Systems](https://determinate.systems).
The letter lists other examples, such as Dolstra blocking longtime contributors from becoming code reviewers or blocking a build-system change that had made it through the RFC process. The letter concludes that Dolstra is essentially leveraging social power from being the founder of the project to overrule decisions that are nominally supposed to be made collaboratively. In short, Dolstra is acting as "the effective Benevolent Dictator for Life (BDFL)" of the project, even though the NixOS Foundation's charter doesn't grant anyone that authority. The letter says this leads to "a culture of responsibility without authority" that erodes contributors' desire to continue working on the project. It specifically mentions the moderation team as an example of this, saying that its members are "in fear of their authority being undermined directly by Eelco or indirectly through the Foundation".
When asked to comment on the concerns raised in the letter, members of the NixOS moderation team responded:
> Overall we think that the letter describes the situation of the moderation team fairly well. We have been operating in an emergency mode most of the time for over half a year now. Our team retention is at an all time low, and we are barely able to keep up with recruiting new members as old ones quit. Right now the moderation team is down to four people, including two who desire to leave as soon as a replacement is found, not counting another moderator who left last week.
>
> To the extent that the moderation team feels disempowered, this is mostly because of heavy antagonism from some community members or risks of destabilizing the community, and not because of an actual lack of power. Most of that is a reflection of a deeper cultural conflict within the community and not directly related to the foundation board.
Despite slightly disagreeing with the source of the issue, they went on to acknowledge that Dolstra had impeded several attempts to improve the situation, and said that they understood many community members' complaints. The team also called the situation itself "a deep structural and cultural issue involving many people".
Pierre Bourdon, a long-time contributor to Nix, [posted on Mastodon](https://mastodon.delroth.net/@delroth/112310645064859357) about his experience working on NixOS, [stating](https://mastodon.delroth.net/@delroth/112310661634038271) that while he disagrees with the tone and approach of the open letter, the factual statements about Dolstra's leadership match his own experience.
#### Conflicts of interest
The letter also alleges several conflicts of interest, primarily concerning Dolstra's employer, Determinate Systems. [Anduril](https://en.wikipedia.org/wiki/Anduril_Industries), a military contractor that uses NixOS, has repeatedly attempted to become a sponsor of NixCon, which did not go over well with the community, as reflected in the minutes of the board meeting on March 20. The letter says Dolstra pushed strongly for the inclusion of Anduril as a sponsor even after it became clear that many core contributors disagreed. Anduril was eventually dropped as a sponsor for both [NixCon 2023](https://2023.nixcon.org/) and [NixCon 2024](https://2024-na.nixcon.org/) after community pressure.
On April 10, Théophane Hufschmitt, the secretary of the board, shared [an update](https://discourse.nixos.org/t/nixos-foundation-event-sponsorship-policy/43110) on the board's [new sponsorship policy](https://github.com/NixOS/foundation/blob/bb7af14ae242ab87c8312bb4122b2a3cd184462d/policies/sponsorship_policy.md). Hufschmitt expressed the board's apologies for the way the situation was handled, and promised that "we will prioritize transparency, inclusivity, and responsiveness in our decision-making processes".
That same day, Samuel Dionne-Riel [stated](https://twitter.com/samueldr/status/1778259760707448853) that Dolstra had refused to clarify whether he had a relationship with Anduril and asked Christensen, a co-founder of Determinate Systems: "Does DetSys have or had relationships with Anduril?" Christensen [replied](https://twitter.com/grhmc/status/1778386025007460682): "Did you know this category of question is pretty much impossible to answer because NDAs are a thing?"
This isn't the only time Dolstra has appeared to avoid disclosing potential conflicts of interest; the letter alleges that he kept his status as a founder of Determinate Systems secret for some months (a claim Dolstra later denied), and that this is especially worrying in light of some of the technical promises that Determinate Systems makes to customers. The company produces its own installer for Nix that the company promises will provide stable support for some Nix features. The
letter states: "This is fine, however, it is questionably acceptable to do that while employing *the lead developer of CppNix* [the main Nix implementation] and saying nothing about how this will interact with the team's [decision-making] autonomy." The concerns are not entirely theoretical, either; the main Nix installer has been [broken in various ways](https://github.com/NixOS/nix/issues/10109) since version 2.18 in September 2023.
#### Call to action
The final section of the letter calls for Dolstra's resignation from the board, suggesting that he should also completely disengage from the project for at least six months, to give the rest of the board time to reform the project's governance.
> This document should be seen as the canary in the coal mine for what *many* people have been feeling for years and does not exhaustively cover absolutely all problems in the community, but we hope it is enough to justify action.
The letter ends by suggesting that if Dolstra doesn't resign, the signatories would switch to and support a fork of the project. I contacted several of the signatories to ask whether they'd be willing to provide additional commentary on why they believed a letter like this to be a necessary step. Haydon Welsh responded:
> I signed the letter because it was clear that every other team member was sick and tired of Eelco, and so I saw it only right if that's their only hope to regain enthusiasm for the project. No open-source project should die or be hard-forked because of one person, that destroys a lot of the purpose for being open-source.
Kiara Grouwstra had stronger feelings on the matter:
> While I want a full rotation of members on the NixOS board, as well as changes to its goal and structure so as to better incorporate the community including marginalized perspectives, my friend convinced me the polemic response would not sit well with the moderators, and shared with me the draft open letter about Eelco's role, which I opted to settle for as the lower-hanging fruit right now.
On April 27, Xe Iaso wrote [a blog post](https://xeiaso.net/blog/2024/much-ado-about-nothing/) about xer perspective on the matter, stating that at this point a fork is both inevitable and doomed. Even if the actions called for in the letter do come about, the difficult situation is already having an impact on the Nix community. On April 21, Nixpgs contributor Kamila Borowska [resigned from the project](https://github.com/NixOS/nixpkgs/pull/305826). On April 25, Mario Rodas, who had contributed more than 250 packages, [followed suit](https://github.com/NixOS/nixpkgs/pull/306702). In total, 24 maintainers [have left](https://github.com/NixOS/nixpkgs/issues?q=label%3A%228.has%3A+maintainer+removal%22).
#### Dolstra's response
On April 26, Dolstra posted [a response](https://determinate.systems/posts/on-community-in-nix/) to the letter. He states that the role of the board is to handle the financial and legal work, not to run the Nix community. He also claims that he has had "very little involvement in Nixpkgs and NixOS in recent years". Dolstra goes on to state: "I am just one member of the five-member Nix team and hold no more formal authority than the others in determining the direction of the team." While this is true, it does not directly refute the letter's claims that Dolstra exceeds the formal authority granted to him.
Dolstra also reiterated his position that NixCon should not refuse Anduril's sponsorship, stating: "It is my opinion that it is not for us, as open source software developers, to decide whose views are valid and whose are not, and to allow or disallow project or conference participation as a result." Dolstra does, however, explicitly refute the claim that his involvement in Determinate Systems was at all secret: "My role, participation, and focus on the good work being done at Determinate Systems have been public knowledge since the company's inception". He goes on to say that the claim that Determinate Systems seeks to have an outsized influence on the community is "patently false".
He ends his response by inviting community members who feel unwelcome in the Nix community to work for Determinate Systems instead:
> I remain committed to creating a community where everyone feels seen, heard, and valued, and I will not let unfounded accusations detract from this important work. I encourage everyone reading this who feels that they have not been heard or feels displaced to join the Determinate Systems community as we continue working to make Nix as easy to use and as impactful as possible.
It is difficult to predict where the Nix community will go from here, and what the eventual fate of any forks will be. For now, Dolstra remains the chair of the board — a position he seems unlikely to give up under pressure from the letter's signatories.
Garry’s Mod faces deluge of Nintendo-related DMCA takedown notices
> Facepunch Studios has announced on Steam that it's removing 20 years' worth of Nintendo-related workshop items for its sandbox game Garry's Mod to comply with the Japanese company's demands. Earlier this year, an X user with the name Brewster T. Koopa posted that a group of trolls was filing false DMCA claims against the game to get Nintendo add-ons removed and to get add-on makers to shut down. The perpetrators allegedly used a fake email to impersonate Nintendo's lawyers to send DMCA takedown notices. Facepunch Studios said in its new announcement, that it believes the demands legitimately came from Nintendo and that it has to respect the company's decision and start taking down items related to its IPs. "This is an ongoing process, as we have 20 years of uploads to go through," the developer wrote. "If you want to help us by deleting your Nintendo related uploads and never uploading them again, that would help us a lot."
The Secrets Factory: The Shadowy Firm Pushing the Limits of Business Privacy
https://www.wired.com/story/registered-agents-inc-fake-personas/
Inside a drab one-story office building in Post Falls, Idaho, a little-known American company has built the machinery that enables hundreds of thousands of businesses to operate in near-total secrecy.
The company, Registered Agents Inc., is a one-stop shop for people seeking to incorporate a business in any US state, often in those with advantageous tax policies, while obscuring their identities. According to five former employees of Registered Agents Inc. or its subsidiaries, the company routinely incorporates thousands of businesses on behalf of its customers using fake personas. Former Registered Agents Inc. employees say that the company’s widespread use of personas is an outgrowth of its founder’s obsession with privacy and a desire to push the boundaries of incorporation laws.
The registered agent industry, which incorporates businesses and acts as a point of contact for legal notices, is already effective at masking the identity of who owns a company. Registered agents have many legitimate uses, and states often require that a company have a registered agent. In some instances, however, these services have benefited “oligarchs, criminals, and online scammers,” according to a 2022 investigation by The Washington Post and the International Consortium of Investigative Journalists. Experts say a lack of adequate federal and state regulations of registered agents helps to make the United States a hotbed for money-laundering and other shady business dealings.
In a typical scenario, a registered agent would incorporate a company on behalf of a customer. An employee of the registered agent company would list their name on the incorporation documents, sometimes providing the company’s email address and office as contact information. That process provides business owners one layer of secrecy, preventing anyone who looks at state records from determining the real owner of a company.
Registered Agents Inc., according to the former employees, routinely goes one step further, incorporating companies in the names of fictional personas created by the company’s founder, Dan Keen. It’s unclear what benefit Registered Agents Inc. or its customers receive when a company is incorporated by a fake identity.
Around the country, at least 1,463 companies incorporated by Registered Agents Inc. list a woman named Riley Park as an organizer or agent, according to a WIRED analysis of publicly available incorporation documents. But Riley Park isn’t a real person, the former employees say. She’s one of multiple fake personas used by Registered Agents Inc. Former employees identified at least 10 fake personas used by the company, including David Roberts, Drake Forester, and Morgan Noble.
Using business records made public by OpenCorporates, a website that shares and standardizes information sourced from business registries around the world, WIRED found 36,257 business listing company officers who share names that former employees say are fake. At least 3,735 of these businesses’ incorporation paperwork references Registered Agents Inc., either explicitly in the paperwork or by using an address known to former employees as belonging to Registered Agents Inc.
WIRED’s analysis found that these companies are registered in 20 different states and appear to provide services ranging from law enforcement training to landscaping. Many of these companies with officers using an alleged fake name were registered to addresses known by sources to belong to Registered Agents Inc. For example, six allegedly fake names were listed as officers for 887 of businesses registered to the same address in Sheridan, Wyoming—an office of Registered Agents Inc.
This is likely an undercount. WIRED looked specifically for company records indicating that Registered Agents Inc. incorporated the company alongside at least one of a dozen false names provided by sources. We additionally looked for companies registered by these same false names associated with addresses previously utilized by Registered Agents Inc. for incorporating thousands of other companies. Sources believe the true number is likely much higher.
Registered Agents Inc. declined to fully answer WIRED’s detailed set of questions about its business practices.
“To put it plainly, your assertions in this question set are outdated and patently wrong about Registered Agents Inc.,” the company said in a statement. “Therefore, at this time Registered Agents Inc. will provide no comment as it is apparent that you, Wired and its editors attempt [to] fit a pre-arranged narrative through publishing false facts and other blatant lies.”
Registered Agents Inc. says that it has offices in every state in the US and in Washington, DC, allowing it to offer its customers the ability to register a business anywhere. Many of those offices are small outfits located near state government offices, so its employees can easily submit paperwork. (The Sheridan office is located just a block away from city hall.)
Registered Agents Inc. has expanded beyond incorporation services, building custom software to manage entire businesses. Last year, it acquired Epik, a domain registrar and web hosting company that had previously catered to far-right extremists.
Much of the company’s high-level operations and development take place in the Pacific Northwest, including Spokane, Washington, and Post Falls, Idaho. The company has two major subsidiaries: Two Barrels LLC, which develops software, and Corporate Tools LLC, which enables its customers to manage the filings of multiple businesses.
“Somebody will hire [Registered Agents Inc.] to create an LLC, and then [Registered Agents Inc. will] sign all that paperwork with fake identities and submit it to the Secretary of State,” says Mikhail Slyusarev, who worked as a senior software engineer at the company for more than six years. “There’s no oversight, you're not really answering to anybody, and you’re just making shit up.”
ON JULY 29, 2015, Registered Agents Inc. updated the name listed on its own incorporation documents it had filed with the Wyoming secretary of state. While Keen had previously signed as president and registered agent of the company, the new registered agent for the company was a man named Bill Havre.
Registered Agent Inc.’s website featured a vivid yarn detailing Havre’s life story, according to an archived version of the site from December 2021. Havre grew up on a small ranch in Wyoming and studied medicine at the University of California, Berkeley in the early 1970s, the bio read. But shortly after enrolling in classes, Havre returned home to Wyoming to tend to a family emergency, eventually starting his own businesses in the state.
“After gaining some insight into the nature of starting a business, Mr. Havre was intrigued by the business entity formation process, particularly concerned by what at the time seemed exorbitant fees paid to attorneys to complete and file corporate formation documents,” the website said.
Havre was once listed on Registered Agent Inc.’s website as the company’s president and executive director. Havre has helped register 491 companies with Registered Agents Inc., WIRED found. He’s also an entirely fabricated persona, five former employees say, an invention of Dan Keen.
That 2015 document is the earliest recorded instance of the company using fake names identified by WIRED. Havre’s name was removed from the company’s website in 2022 following inquiries from The Washington Post and the International Consortium of Investigative Journalists.
The Wyoming incorporation paperwork viewed by WIRED includes the full text of the state law against filing a false document, reminding registrants that doing so may be a felony punishable by up to two years in prison and a $2,000 fine. Former employees say that customers of Registered Agents Inc. typically aren’t aware that a fake name is used to sign their company’s incorporation documents.
Provided a copy of the Wyoming incorporation document, experts say using a fake person would likely violate the law. “This does look like it requires a real person to sign—Riley Park would seemingly be in violation,” says Gary Kalman, the executive director of Transparency International US, an anti-corruption group.
Former Registered Agents Inc. employees allege that Keen justified using fake names by saying it was a way to protect employees from being drawn into legal battles and being forced to testify about the company’s customers.
The laws for incorporating companies in America are decided at the state level, allowing a prospective business owner to shop around based on tax advantages, anonymity rules, and other considerations. Many state offices don’t fully investigate filings to determine if the signatories are legitimate, former employees of Registered Agents Inc. say.
“There is no federal requirement, there is no state-level requirement that these registered agents have any code of ethics. There’s no anything,” says Sarah Beth Felix, an expert on financial transparency. “For being essential gatekeepers to legitimize businesses, they’re grossly unregulated.”
Former employees say that the registered agents industry benefits from relaxed incorporation laws in states like Wyoming and Montana, where registering a completely anonymous company is as simple as paying a registered agent service as little as $200. That makes the US an appealing location for illicit financial activity even before the added layer of opacity by a registered agent.
According to two former employees, the company doesn’t screen to see if its customers are real people, or even if their email addresses are legitimate. Former employees say they raised concerns about not knowing the true identity of all of their customers to company leadership, but were dismissed. Experts and former employees said that verifying the identity of its customers is often not required for registered agents.
“You could say your name was Billy Bob and your email was BillyBob123, and we would have created an LLC for you,” the former software developer says.
“Dan takes it almost to an extreme. He tries to maximize what the laws allow in each state,” says Don Evans, who worked in a chief technical officer role at the company. “If people find ways to use his services that are in the gray area, he would turn a cheek to it.”
SINCE 2008, DAN Keen has grown his business from a small company serving customers in the Pacific Northwest to a major national player in what’s known as the corporate formation industry. The company and its competitors offer the ability to incorporate a business in the state of a customer’s choosing and receive mail and legal notices.
Keen started the company after running a tree trimming and landscaping business. Former employees said Keen worked tirelessly to build the business, often sending emails at all hours of the night.
“Dan put in a lot of effort, he worked nonstop,” says Matt MacKenzie, who worked as a legal compliance specialist for more than 11 years and was one of the company’s earliest employees.
When the company was a small upstart, Keen regularly listed his name on the formation documents of the company and its various subsidiaries in states across America. “It wasn't until down the road a couple years later, where he started wanting to use full-on fake names and take his name off all the corporate paperwork for Registered Agents Inc.,” MacKenzie says.
Keen is described by former employees as a driven but eccentric businessman who is prone to micromanagement and sudden shifts in mood. Keen dresses modestly, former employees say, wearing shorts and flannel shirts, and is an avid skier and outdoorsman.
Keen often took a passive aggressive approach with his staff, according to six former employees. Two recounted Keen begrudgingly offering health care plans to employees after being told it was required by the Affordable Care Act, allegedly telling his staff they were “whiners and complainers” for asking for it.
Multiple former employees described Keen as “inappropriate,” saying he often made comments about employees' physical appearance. Two former employees described him as making misogynistic statements, which allegedly included making sexual comments about women and frequently questioning their ability to perform their job.
Several former employees questioned the high-security nature of the office, which they say was filled with security cameras and required them to lock their cell phones in boxes. Slyusarev, Registered Agents Inc.’s former senior software engineer, says the phone system, which he says he installed, was capable of surreptitiously recording employee phone calls.
Former employees say that Keen chafed at government regulations and exercised complete control over the company and its operations. Keen has no website or social media profiles and doesn't give interviews about his business.
“He thinks people are out to get him, or out to get the company,” Evans, the former senior employee, claims.
Details about its inner workings, including the ownership and management structure, are concealed from employees, who say they were discouraged from discussing it at the office. And the practice of using fake personas extends even to Registered Agents Inc.’s own workers.
When Don Evans began interviewing at Registered Agents Inc., he recalled first speaking over LinkedIn with Diane Brunner, who identified herself as a recruiter at the company. When he arrived at the office for an interview, he asked to speak with Brunner and was told nobody by that name works at the company.
Jack Stephenson, who claims to be a vice president and client relations director at Registered Agents Inc. on LinkedIn, is another fake persona, employees say. Stephenson frequently comments on the registered agents industry on LinkedIn. He lists a Bachelor of Business Administration from Utah State University on his profile, but an official from the university told WIRED they couldn’t find any records pertaining to Jack Stephenson.
Understanding Bitcoin Privacy with OXT — Part 4
> It is unlikely that users reading this are looking to become “experts” in chain analysis, but a fundamental understanding of the tools and concepts used to attack their privacy will allow them to better protect their privacy. In this section we will introduce the real world implications of sending and receiving transactions on user privacy. From there we will present specific privacy enhancing technologies that can be used to maintain privacy when interacting with bitcoin.
Understanding Bitcoin Privacy with OXT — Part 3
> Previously, we introduced change detection heuristics for simple spends with 1 input and 2 outputs. We assumed that the transaction included a payment and change output. In reality, a simple spend has many additional interpretations based on the UTXO “ownership model”. The ownership model attempts to assign ownership to the inputs and outputs of a transaction. The complete ownership interpretations for a transaction with 1 input and 2 outputs are shown in Fig 3.1.
Understanding Bitcoin Privacy with OXT — Part 2
> Now that we have presented the basic concepts in Part 1, we can move on to the core concepts that underpin chain analysis by expanding our analyses to include “external” transaction data.
Understanding Bitcoin Privacy with OXT — Part 1