Listen to this Post
A Trusted Editor Becomes the First Step of the Attack
Cryptocurrency developers have become an increasingly attractive target for cybercriminals because a single compromised development machine can expose far more than source code. Wallet credentials, exchange API keys, cloud accounts, SSH keys, private repositories, browser sessions, and blockchain infrastructure may all be accessible from the same workstation.
That is exactly what makes the discovery of the malicious “Solidity Pro” VS Code extension so concerning. What appears to be a specialized development assistant for Solidity programmers is actually part of a multi-stage malware campaign that begins inside Microsoft’s popular code editor and eventually launches an independent Python process capable of surviving after the editor has been closed.
Security researchers at Yeeth Security identified malicious packages associated with names including helper-beeps.solidity-pro and web3devtoolsx.solidity-pro. The extensions reportedly advertise features such as Solidity development assistance, AI-powered auditing, Web3 analytics, and gas analysis. Behind those attractive promises, however, the extensions perform behavior much closer to a downloader and information-stealing platform.
Why Cryptocurrency Developers Are Such Valuable Targets
The cryptocurrency ecosystem concentrates highly valuable secrets on developer computers. A blockchain engineer may simultaneously have access to wallet files, private keys, deployment credentials, RPC endpoints, cloud environments, Git repositories, CI/CD systems, API credentials, and messaging platforms used by development teams.
A malicious extension does not necessarily need to compromise the blockchain itself.
It only needs to compromise the person who has the keys.
This makes developer tooling an especially powerful attack surface. Developers routinely install packages, extensions, SDKs, plugins, command-line tools, and debugging utilities. The assumption is often that these components are there to make development safer or faster.
Attackers are exploiting that trust.
“Solidity Pro” Looks Like a Developer Productivity Tool
The malicious extensions reportedly presented themselves as legitimate Solidity-oriented tools. Their names and functionality were designed to fit naturally into the Web3 development ecosystem, where developers regularly use specialized extensions for smart-contract development, auditing, optimization, and transaction analysis.
That makes the campaign particularly dangerous because there is no obvious reason for a developer to become suspicious immediately after installation.
The extension can appear to be doing exactly what the user expects while performing malicious operations in the background.
The Attack Does Not Happen Immediately
One of the most interesting aspects of the campaign is the use of a substantial execution delay.
Early versions of the malicious extension, reportedly ranging from v1.0.0 through v2.4.x, contained components with seemingly legitimate names such as Web3Analytics and ApiClient.
After activation, however, the extension could wait anywhere from 12 to 72 hours before progressing to the next stage.
This is not an accident.
A delayed execution mechanism can make malicious extensions significantly harder to detect through automated security systems. A marketplace scanner may install the extension, execute it for a short period, observe nothing obviously malicious, and conclude that the package is harmless.
The attacker simply waits.
The Long Game Helps Evade Security Analysis
Security researchers and automated malware sandboxes frequently operate within limited observation windows. If malicious behavior does not occur during that window, the analysis may produce a clean result even though the software is programmed to become dangerous later.
The 12-to-72-hour delay therefore becomes an evasion mechanism.
It also creates a psychological advantage for the attacker. By the time malicious activity begins, the victim may have forgotten that the extension was installed or may already have incorporated it into their normal development workflow.
Cloudflare Workers Become Part of the Delivery Infrastructure
Once the malicious extension decides to proceed, it communicates with attacker-controlled infrastructure.
The campaign reportedly assembles Cloudflare Worker endpoints from encoded fragments, making the infrastructure less obvious during static analysis.
This is another important technique.
Cloudflare services are legitimate and widely used across the internet. Using them does not automatically make malicious traffic suspicious. Attackers can take advantage of this trusted infrastructure to make command-and-control communication blend into normal web traffic.
Legitimate APIs Can Be Used as Decoys
Some versions of the extension reportedly make legitimate-looking requests to the CoinGecko API.
At first glance, this can look completely reasonable for a cryptocurrency development tool. A Web3 extension might legitimately retrieve token prices, market information, or cryptocurrency metadata.
But in this case, the legitimate request can function as camouflage.
The malware communicates with its real infrastructure while simultaneously generating traffic that appears consistent with the advertised functionality of the extension.
The Payload Arrives Encrypted
The malicious server reportedly responds with an AES-GCM-encrypted payload.
Encryption itself is obviously not malicious. Developers use encrypted communication and encrypted data every day. The problem is what happens after the encrypted content reaches the extension.
The extension derives a decryption key from a hard-coded passphrase, decrypts the payload, and writes the resulting Python code to disk.
The seemingly harmless extension has now transformed into a malware delivery mechanism.
VS Code Becomes Only the Beginning
The decrypted Python payload is reportedly launched through Node.js using child_process.spawn.
This is one of the most important technical details in the campaign.
The malicious code is no longer restricted to the normal functionality of the extension. Instead, the extension becomes the initial execution point for a separate process.
In other words, the attacker uses VS Code as the doorway rather than the final destination.
The Detached Process Creates a More Persistent Threat
The spawned Python process is reportedly detached from the VS Code extension host.
That distinction dramatically changes the threat model.
If a developer notices something unusual and closes VS Code, the malicious process may continue operating independently.
Closing the editor therefore does not necessarily terminate the attack.
This is a powerful technique because users naturally assume that anything executed by an editor extension should disappear when the editor disappears. A detached process breaks that assumption.
Hidden Python Files Make the Activity Less Obvious
Some observed samples reportedly write the Python payload to a temporary filename resembling:
.vscode_sol_analytics_.py
Other variants use randomized filenames and may place the payload inside locations associated with the user’s home directory.
The naming strategy is noteworthy because the malware attempts to look connected to the development environment.
A filename containing terms such as vscode, sol, or analytics can appear less suspicious than an obviously malicious filename.
The Malware Checks for Automated Environments
Before deploying the payload, the malware reportedly checks environmental variables associated with development automation and hosted environments.
Examples include:
CI
GITHUB_ACTIONS
JENKINS_HOME
GITPOD_WORKSPACE_ID
If these indicators are present, the malware may avoid executing.
This behavior strongly suggests that the attackers are thinking beyond individual developer laptops.
They are attempting to determine whether they have landed inside an automated development or CI/CD environment.
CI/CD Environments Could Be Extremely Valuable
A developer workstation might contain credentials belonging to one person.
A CI/CD environment can potentially contain credentials belonging to an entire organization.
Build servers frequently have access to package registries, cloud accounts, deployment systems, source repositories, signing credentials, container registries, and production infrastructure.
For an attacker, identifying and avoiding automated analysis environments can also prevent researchers from easily reproducing the malicious behavior.
That makes environment detection useful for both target selection and sandbox evasion.
The Campaign Evolves After Version 3.1.0
The operation reportedly changed substantially beginning with version 3.1.0.
Instead of relying primarily on a Python dropper, newer builds became more capable information stealers.
This evolution is significant because it demonstrates that the attackers were not simply distributing a static malicious extension.
They were actively developing the campaign.
The objective shifted toward systematically harvesting valuable information from the infected machine.
Browser Profiles Become a Treasure Chest
Newer versions reportedly search browser profiles for sensitive information.
Modern browsers can contain session data, authentication artifacts, saved credentials, cookies, extension data, and other information that can potentially help attackers impersonate users or access accounts.
For cryptocurrency developers, browser compromise can be particularly damaging because Web3 applications are frequently accessed through browser-based wallets and decentralized applications.
A compromised browser session may therefore become a bridge toward financial theft.
Wallet Data Is a High-Value Target
The campaign also reportedly searches for local cryptocurrency wallet data.
This is perhaps the most obvious reason attackers would specifically target Solidity and Web3 developers.
A developer may have test wallets, deployment wallets, development credentials, blockchain API tokens, signing infrastructure, or other sensitive assets stored locally.
Even wallets that do not contain substantial funds can be valuable because their associated credentials may reveal additional infrastructure.
SSH Keys Can Open Another Door
The reported targeting of SSH keys raises the stakes even further.
SSH credentials can provide access to servers, cloud instances, development environments, Git infrastructure, and administrative systems.
An attacker who obtains an SSH key does not necessarily need to steal cryptocurrency immediately.
They may use the key to move deeper into the victim’s organization.
This creates the possibility of a multi-stage intrusion where the initial extension compromise is only the first foothold.
Cloud Credentials Could Turn a Developer Infection Into an Enterprise Breach
Cloud credentials are another particularly dangerous target.
Modern development teams commonly interact with AWS, Azure, Google Cloud, container platforms, storage systems, databases, serverless infrastructure, and deployment pipelines.
If those credentials are exposed, attackers may be able to move from a developer’s laptop into cloud infrastructure.
The potential consequences include unauthorized resource creation, data theft, cryptocurrency mining, lateral movement, service disruption, and further credential harvesting.
Source-Control Tokens Are Equally Dangerous
GitHub and other source-control platforms often sit at the center of modern software development.
Source-control tokens can provide access to private repositories, code, issue trackers, packages, secrets, and automation systems.
A compromised developer token can therefore become a supply-chain attack vector.
An attacker who obtains repository access may potentially modify code, introduce malicious dependencies, steal intellectual property, or compromise downstream users.
API Keys Expand the Attack Surface
The reported targeting of API keys adds another layer to the campaign.
Developers frequently store API credentials for blockchain nodes, analytics platforms, cloud services, AI providers, payment systems, monitoring tools, and internal applications.
A single infected machine could therefore provide attackers with credentials belonging to multiple unrelated services.
This is one reason credential theft is often more valuable than simply stealing files.
Telegram Tokens Reveal the Broader Operational Focus
The reported targeting of Telegram bot tokens is another unusual but revealing detail.
Telegram bots are frequently used for development notifications, trading systems, monitoring, automated alerts, community management, and operational workflows.
Compromising a bot token can allow attackers to impersonate the bot or potentially manipulate automated processes.
It demonstrates that the malware is designed to search broadly for credentials rather than focusing exclusively on cryptocurrency wallets.
Possible Links to WhiteCobra Require Caution
Researchers have reportedly identified similarities between the
Earlier campaigns associated with that activity used fake Solidity-focused extensions and marketplace manipulation to target users of VS Code, Cursor, and Open VSX.
However, similarity does not automatically prove that the same threat actor is responsible.
The observed samples are technically distinct, meaning attribution should remain cautious until stronger evidence emerges.
Cybersecurity attribution is rarely as simple as finding two campaigns using similar themes.
Attackers copy successful techniques.
Different groups can target the same community.
And malware developers frequently reuse public ideas.
Why Solidity Extensions Keep Appearing in Malware Campaigns
The repeated targeting of Solidity developers is not surprising.
Ethereum and other blockchain ecosystems have created a specialized development environment filled with high-value credentials and financial infrastructure.
A malicious Solidity extension therefore offers attackers an unusually attractive combination:
Developer trust.
Privileged local access.
Financially valuable credentials.
Cloud access.
Source-code access.
And potentially direct access to blockchain infrastructure.
The attacker does not need to attack the blockchain protocol when the developer workstation provides a much easier target.
Deep Analysis
The Real Attack Chain
The campaign can be understood as a sequence of stages:
Stage 1 — Social Engineering:
The attacker publishes an extension designed to look useful to Solidity and Web3 developers.
Stage 2 — Trust Establishment:
The extension presents legitimate-looking development, auditing, analytics, or gas-analysis functionality.
Stage 3 — Delayed Execution:
The malicious logic waits for a randomized period between roughly 12 and 72 hours.
Stage 4 — Infrastructure Discovery:
Encoded fragments are used to construct attacker-controlled Cloudflare Worker endpoints.
Stage 5 — Payload Retrieval:
An encrypted payload is downloaded from the remote infrastructure.
Stage 6 — Decryption:
The extension derives a key from a hard-coded passphrase and decrypts the payload.
Stage 7 — File Creation:
The decrypted Python code is written to the local filesystem.
Stage 8 — Process Execution:
Node.js launches the Python payload using child_process.spawn.
Stage 9 — Process Detachment:
The Python process becomes independent from the VS Code extension host.
Stage 10 — Environment Detection:
The malware checks for CI/CD and hosted development environments.
Stage 11 — Credential Discovery:
The newer builds search browsers, wallets, SSH keys, cloud credentials, source-control tokens, API keys, and Telegram tokens.
Stage 12 — Potential Lateral Movement:
Stolen credentials can potentially provide access to repositories, cloud systems, servers, and other infrastructure.
What Defenders Should Investigate
Security teams should examine developer workstations for recently installed Solidity, Web3, blockchain, auditing, or AI-assisted coding extensions.
Unexpected Python processes originating from VS Code deserve particular attention.
The following Linux commands can help identify suspicious Python processes:
ps aux | grep -E 'python|python3'
Inspecting Running Processes
Security teams can also examine process relationships to determine whether a Python process was spawned from a code editor:
pstree -ap | grep -E code|python|node
This can help identify unusual parent-child relationships involving VS Code, Node.js, and Python.
Searching for Suspicious Files
Defenders can search common temporary locations for suspicious Python files:
find /tmp /var/tmp "$HOME" -type f \n( -name '.py' -o -name 'vscode' -o -name 'sol' ) \n-mtime -7 2>/dev/null
This should be treated as an investigative technique rather than a definitive malware detector.
Checking for the Reported Environment Variables
Organizations can audit their development environments for variables referenced by the malware:
env | grep -E '^(CI|GITHUB_ACTIONS|JENKINS_HOME|GITPOD_WORKSPACE_ID)='
The presence of these variables alone is not malicious. Their importance comes from understanding whether suspicious software is actively checking them.
Searching VS Code Extension Data
On systems where VS Code extensions are stored under the user’s home directory, defenders can investigate recently modified extension directories:
find "$HOME/.vscode/extensions" -maxdepth 2 -type f \n-printf '%TY-%Tm-%Td %TH:%TM %p ' 2>/dev/null | sort -r | head -100
Organizations should compare installed extensions against approved software inventories.
Looking for Node.js Child Processes
Because the reported attack chain uses Node.js to launch the Python payload, process monitoring can be useful:
ps -eo pid,ppid,user,cmd --forest | \ngrep -E 'node|python|code'
Unexpected relationships deserve deeper investigation.
Network-Level Investigation
Security teams should also investigate outbound connections from VS Code and its child processes.
Particular attention should be paid to connections that appear shortly after extension activation, especially when they involve Cloudflare-hosted infrastructure combined with unexpected encrypted payload retrieval.
Network telemetry can be more reliable than filenames because attackers can easily change filenames while still needing to communicate with infrastructure.
Credential Rotation Must Come First
If a malicious extension is confirmed to have executed, simply deleting the extension is not enough.
Potentially exposed credentials should be treated as compromised.
That can include:
SSH keys.
Cloud access keys.
GitHub and source-control tokens.
API keys.
Blockchain RPC credentials.
Wallet credentials.
CI/CD secrets.
Telegram bot tokens.
Browser session credentials.
The correct response depends on the specific environment, but credential revocation and rotation should be prioritized before assuming the workstation is clean.
Why Removing the Extension May Not Remove the Malware
This is perhaps the most important defensive lesson.
The extension is only the initial delivery mechanism.
Once the Python process has been detached, deleting the extension may not terminate the malicious process or remove files and persistence mechanisms already created by the attacker.
Incident responders therefore need to investigate the operating system itself rather than treating the event as a simple extension uninstall.
What Undercode Say:
The Developer Workstation Has Become a Security Perimeter
Modern software development has changed dramatically.
The developer laptop is no longer just a machine used to write code.
It is often a gateway to cloud infrastructure, source repositories, production systems, cryptocurrency wallets, CI/CD platforms, and sensitive company credentials.
That makes developer tooling a security boundary.
Extensions Deserve the Same Suspicion as Packages
Developers have become accustomed to reviewing npm and PyPI dependencies.
VS Code extensions deserve similar scrutiny.
An extension can execute code with access to the local environment, which means its security implications can be far greater than those of a simple graphical customization.
Marketplace Trust Is Not Absolute
The existence of an extension inside an official or popular marketplace should not be interpreted as proof that the software is safe forever.
Attackers increasingly attempt to manipulate reputation, naming, descriptions, download counts, and user expectations.
Security teams need independent controls.
Delayed Execution Is a Major Warning Sign
The 12-to-72-hour delay is especially concerning.
It demonstrates how attackers can design malware specifically around automated security testing limitations.
A clean sandbox result does not necessarily mean clean software.
Developers Need Better Software Supply-Chain Hygiene
Installing an extension should be treated as installing executable software.
Organizations should maintain approved extension lists, monitor extension installations, and restrict development environments where appropriate.
Cryptocurrency Developers Face an Unusually High Risk
The combination of source code and financial credentials makes blockchain development environments particularly attractive.
A single compromised machine can potentially expose both intellectual property and financial assets.
AI Features Can Become a Social-Engineering Advantage
The inclusion of AI auditing or AI-assisted development features is also strategically interesting.
AI is now a powerful marketing keyword in developer tooling.
Attackers can exploit that enthusiasm by creating extensions that promise automated code review, vulnerability detection, optimization, or smart-contract analysis.
The more attractive the feature sounds, the less attention users may pay to the underlying permissions and behavior.
Fake Security Tools Are Particularly Dangerous
A malicious extension pretending to be an auditing tool creates an especially dangerous contradiction.
Users install it because they want to improve security.
The tool then becomes the security problem.
Cloudflare Is Not a Sign of Safety
Attackers can use legitimate infrastructure providers for malicious purposes.
Seeing Cloudflare in network traffic should not automatically trigger an assumption of legitimacy.
Security decisions must be based on behavior, destination reputation, context, and process relationships.
Detached Processes Change Incident Response
The ability to survive after VS Code closes means responders need to think at the operating-system level.
The editor is merely the launcher.
The actual malware may continue operating elsewhere.
CI/CD Detection Shows Attacker Maturity
Checking for GITHUB_ACTIONS, Jenkins, Gitpod, and generic CI indicators suggests that the attackers understand development environments.
This is not merely consumer malware accidentally landing on a developer’s laptop.
The campaign appears designed around modern software-development workflows.
Source-Control Theft Could Create Secondary Attacks
Stealing credentials is dangerous.
Using those credentials to modify repositories is potentially much worse.
A compromised GitHub token could potentially become the starting point for a second supply-chain compromise.
The Same Problem Could Spread Beyond Solidity
There is nothing inherently limiting this technique to Solidity.
The same model could target extensions for Rust, Python, JavaScript, Kubernetes, AWS, Docker, AI development, cybersecurity, or any other specialized ecosystem.
Attackers go where trust and valuable credentials intersect.
Security Teams Need Extension Telemetry
Endpoint detection systems should monitor extension installation and execution.
Organizations should know which extensions are installed, when they were installed, who installed them, and what processes they launch.
Without this visibility, malicious extensions can become invisible entry points.
Developers Should Separate Wallet Operations From Development Machines
Where possible, highly sensitive wallet operations should not depend on the same workstation used for downloading random developer tooling.
The more privileges concentrated on one machine, the greater the potential impact of compromise.
Secrets Should Never Depend on Developer Convenience
API keys and cloud credentials stored locally make development easier.
They also make malware more valuable.
Short-lived credentials, hardware-backed authentication, secret managers, and least-privilege access can dramatically reduce the damage caused by workstation compromise.
The Supply Chain Is Expanding
Software supply-chain security used to focus heavily on libraries.
Now the attack surface includes extensions, plugins, AI coding assistants, package managers, IDE integrations, build tools, and developer agents.
Every new productivity layer introduces another potential execution path.
The Biggest Risk Is Invisible Execution
The most dangerous malware is often not the malware that produces a dramatic warning.
It is the software that quietly performs legitimate-looking work while executing something else.
“Solidity Pro” illustrates that problem perfectly.
Closing the Door Requires More Than Uninstalling an Extension
Once malicious code has executed, incident response must assume that credentials may have been exposed.
Removing the original extension is only one step.
Processes, files, credentials, network activity, persistence mechanisms, and account access must all be examined.
The Lesson for the Web3 Community
Web3 developers are not simply defending source code.
They are defending financial infrastructure.
That distinction matters.
A compromised development environment can become the bridge between a seemingly minor software installation and a major financial or organizational breach.
The Future of Developer Security Will Be More Restrictive
As development environments become increasingly automated and powerful, security controls will need to become more sophisticated as well.
The days when developers could install any extension they wanted without organizational oversight are becoming harder to justify in high-value environments.
Trust Must Become Verifiable
The fundamental lesson is simple:
Do not trust an extension because it looks legitimate. Trust it only after its behavior has been verified.
That principle will become increasingly important as attackers continue moving toward the developer ecosystem.
✅ The “Solidity Pro” Campaign Is Technically Plausible and Consistent With Known Attack Patterns
The reported chain — malicious extension, delayed execution, encrypted payload retrieval, Python execution, and credential theft — is technically consistent with modern malware techniques targeting developer environments.
The use of Node.js to spawn external processes is particularly relevant because VS Code extensions can interact with the local operating system.
The reported targeting of browser data, SSH keys, cloud credentials, source-control tokens, API keys, and cryptocurrency-related information also aligns with the high-value credential profile of developer machines.
✅ Detached Execution Can Allow Malware to Continue After VS Code Closes
A detached child process can operate independently of the original editor process.
Therefore, closing VS Code does not inherently guarantee that a process launched by an extension has stopped.
This makes process-tree and endpoint investigation important during incident response.
⚠️ Attribution to WhiteCobra Should Remain Unconfirmed
Tradecraft similarities can provide useful clues, but they are not enough to establish definitive attribution.
Different threat actors can reuse extension themes, infrastructure providers, delivery mechanisms, and credential-stealing techniques.
The safest assessment is that the campaign may share characteristics with previously reported activity while requiring additional evidence before being confidently attributed to the same operator.
❌ Removing the Extension Alone Is Not a Complete Remediation Strategy
If the extension successfully launched a detached payload, uninstalling the extension does not necessarily remove the separately running malware.
Affected systems should therefore be investigated for processes, files, persistence, network connections, and credential exposure.
Potentially compromised credentials should also be rotated rather than assuming the system is safe after deleting the extension.
Prediction
(+1) Developer Extension Security Will Become a Major Enterprise Priority
The most likely positive development is that organizations will increasingly treat IDE extensions as part of the software supply chain rather than harmless productivity accessories.
Enterprise security teams are likely to introduce extension allowlists, behavioral monitoring, automated reputation checks, and endpoint detection for suspicious child processes launched by development tools.
(+1) Web3 Development Environments Will Adopt Stronger Isolation
Cryptocurrency developers are likely to move toward more isolated development environments, hardware-backed wallet security, short-lived credentials, and stronger separation between coding systems and financial operations.
That separation could significantly reduce the impact of malicious tooling.
(-1) Attackers Will Continue Weaponizing Developer Productivity Tools
The negative prediction is equally clear.
As developers install increasingly powerful AI assistants, extensions, plugins, agents, and automation tools, attackers will have more opportunities to disguise malware as productivity software.
The next “Solidity Pro” may not call itself Solidity Pro at all.
It could advertise itself as an AI security auditor, autonomous coding agent, cloud deployment assistant, smart-contract optimizer, or vulnerability scanner.
(-1) The Attack Surface Will Move Closer to the Developer
The industry is rapidly turning developer environments into highly privileged automation platforms.
That creates an uncomfortable reality: the tools designed to make developers more productive can also give attackers powerful execution capabilities.
The battle for software security is therefore moving closer to the keyboard itself.
Final Takeaway: The Extension Was Never the Real Target
The most important lesson from the “Solidity Pro” campaign is that the extension was only the first stage of the attack.
The real target was the
Once an attacker gains a foothold inside that environment, the potential prize extends far beyond a single computer. Wallets, source repositories, cloud accounts, SSH infrastructure, API services, CI/CD systems, and organizational secrets can all become part of the attacker’s reach.
For developers, the warning is straightforward: treat IDE extensions as executable software, not harmless add-ons.
For security teams, the message is even stronger: monitor what developer tools execute after installation, investigate detached processes, enforce extension controls, and assume credentials may be exposed whenever untrusted code successfully runs.
The modern software supply chain no longer begins when a package enters production.
Sometimes, it begins when a developer clicks Install.
🕵️📝Let’s dive deep and fact‑check.
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
References:
Reported By: cyberpress.org
Extra Source Hub (Possible Sources for article):
https://www.pinterest.com
Wikipedia
OpenAi & Undercode AI
Image Source:
Unsplash
Undercode AI DI v2
🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]
📢 Follow UndercodeNews & Stay Tuned:
𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky | 🐘Mastodon | 📺Youtube
