SOFTWARE DEVELOPERS, BEWARE! What Looks Like a Job Interview Could Actually Be a Cyberattack Attempt.
A few days ago, someone reached out to me on LinkedIn with an opportunity to participate in an international software development project.
At first glance, the proposal seemed entirely professional: a Web3-based vehicle marketplace, React Native, blockchain technologies, a fully remote working model, and attractive compensation.
In other words, it looked no different from the international project and collaboration opportunities we occasionally encounter on LinkedIn.
However, what began as an ordinary professional conversation unexpectedly turned into a cybersecurity experience as the meeting progressed and I encountered a series of suspicious requests.
Afterward, my research led me to a serious, internationally documented cybersecurity threat specifically targeting software developers.
1. Initial Contact — Everything Seemed Perfectly Normal
Someone contacted me through LinkedIn to discuss a Web3-based project they were developing and the technical expertise they were looking for.
They shared information about the project’s scope, technology stack, and working arrangements.
Initially, I considered it a routine professional interaction. I thought the conversation could be worthwhile, particularly as an opportunity to learn more about the technical approaches and development practices used in international technology projects.
2. The Meeting Was Scheduled — Everything Appeared Professional
Following our initial messages, a meeting was arranged through Calendly.
I was informed that the discussion would take place on Zoom.
I decided to attend to better understand the project’s technical architecture, development processes, and potential collaboration model.
Up to this point, nothing had struck me as unusual.
3. A Different Person Joined the Meeting — The First Questions Emerged
When I joined the Zoom meeting, I was greeted by someone other than the person who had originally contacted me on LinkedIn. This individual was introduced as the project manager.
Since it is perfectly normal to interact with different team members during technical discussions, I did not initially consider this a problem.
However, the meeting soon took a very different direction from what I had expected.
4. A Source Code Repository Was Shared — My First Suspicions Arose
During the meeting, I was sent a Bitbucket repository link and asked to open it.
The first thing that caught my attention was that the repository was public.
Based on my experience in software development, companies generally keep the source code of their commercial projects in private repositories.
Of course, open-source projects are an exception. However, the fact that a repository presented as a commercial product was publicly accessible raised my first question.
Still, I did not want to assume malicious intent.
“Could this be a sample project prepared for a technical assessment? Perhaps they want me to review the code and provide feedback as part of a test case.”
After all, these types of assessments are not uncommon in technical interviews. Developers may be asked to review existing code, identify issues, or explain how they would improve a particular implementation.
For that reason, I initially tried to approach the situation as a normal technical evaluation.
Nevertheless, I was dealing with a project whose technical implementation, origin, and security I had not yet verified.
I therefore decided to perform some basic checks before opening the link.
5. The Screen-Sharing Request — My Concerns Continued to Grow
First, I examined the link I had received.
The URL belonged to Bitbucket’s official domain, and the repository was genuinely hosted on the platform and publicly accessible.
In other words, it was not a link redirecting me to an obviously fraudulent or unfamiliar website.
However, I was fully aware that a repository being hosted on a legitimate platform does not automatically mean its source code is trustworthy.
After completing these initial checks, I opened the Bitbucket repository in my browser.
I was then asked to share my screen.
I agreed to share only my Chrome browser window and began reviewing the source code.
To be fair, I did not notice anything immediately suspicious during my initial inspection.
Quite the opposite: the project appeared well-structured and professionally organized.
It was a React-based application. Its folder structure, separation of concerns, and overall architecture closely resembled patterns commonly found in enterprise software projects.
Even the commit history appeared carefully maintained.
There were consistent commits, a seemingly coherent project structure, and code organized in a way that looked reasonable at first glance.
In short, my preliminary review revealed no obvious warning signs.
For a moment, I genuinely considered the possibility that I was looking at a professionally developed application.
However, my inspection was limited to browsing the repository. I had not performed a comprehensive security review of the code.
After a while, I was told that sharing only my browser window was insufficient.
Instead, I was asked to share all my screens.
This was the point at which my concerns grew significantly, and I declined the request.
I could not understand why individuals whose identities and intentions I had not independently verified needed such broad visibility into my computer.
One question immediately came to mind:
“Why am I being asked to provide this level of visibility when I have not yet verified who these people are or whether the project is trustworthy?”
From that moment on, my attention shifted away from the technical discussion and toward the potential security risks of the interaction.
6. I Was Asked to Run the Project — I Ended the Meeting
After I refused to share all my screens, I received another request.
This time, I was asked to clone the repository onto my own computer and run the application locally.
The explanation was that they wanted to see the application running and conduct a UI review.
At this point, my suspicions developed into serious security concerns.
First, they had requested access to all my screens.
Now, they expected me to execute a project whose origin and security I had not verified.
I found myself asking:
“Why should I run an unfamiliar project directly on my own computer when I have not fully reviewed its implementation or established that it is safe?”
Get Serkan AĞCA’s stories in your inbox
Join Medium for free to get updates from this writer.
The sequence of requests made me increasingly concerned that the individuals involved might have malicious intentions.
I decided not to continue the meeting.
Considering the potential risks of executing unverified code on my computer, I declined the request.
The other party accepted my decision, and we ended the call.
I did not download, clone, or execute any code, nor did I grant anyone remote access to my computer.
However, what happened after the meeting raised even more questions.
7. The Repository Became Inaccessible — This Was Particularly Concerning
Shortly after the meeting, I decided to check the Bitbucket repository again.
However, the link that had been accessible just moments earlier was now returning:
404 — Repository not found
Interestingly, the associated Bitbucket workspace was still accessible.
Of course, there can be many legitimate reasons why a repository becomes unavailable.
However, the combination of being asked to execute the project locally and then finding that the repository was no longer accessible prompted me to investigate the experience more thoroughly.
8. My Investigation — I Discovered an International Cybersecurity Threat
After the meeting, I began researching similar incidents.
I discovered reports describing software developers in different parts of the world being targeted through remarkably similar techniques.
One particularly relevant attack campaign is known as:
🔴 CONTAGIOUS INTERVIEW — Fake Job Interview Attacks
In these attacks, threat actors approach developers through professional platforms such as LinkedIn, often presenting attractive employment or collaboration opportunities.
They then use technical interviews or coding assessments as a pretext to persuade developers to execute projects hosted on platforms such as GitHub, GitLab, or Bitbucket.
Malicious code hidden within these projects may attempt to steal SSH keys, API tokens, corporate credentials, cryptocurrency wallet information, and other sensitive data.
These techniques have also been documented by security researchers at major technology companies, including Microsoft and Atlassian.
An important clarification: I have not technically confirmed that the individuals I spoke with were associated with this campaign or that the repository they shared contained malicious code.
Nevertheless, the similarities between my experience and the documented attack techniques were striking enough to warrant serious attention.
⚠️ A Few Important Reminders for Fellow Software Developers
- Never execute unverified projects directly on your computer. Establish the source and trustworthiness of the code first.
- Remember that even seemingly routine commands such as npm install can trigger unexpected code execution.
- Independently verify the identities of recruiters, companies, and project representatives who contact you through professional platforms.
- Exercise additional caution on corporate devices, particularly those containing SSH keys, access tokens, or other sensitive information.
- Carefully evaluate requests involving screen sharing, remote access, or immediate execution of unfamiliar code.
We should never have to compromise our personal or corporate security to demonstrate our technical abilities during a job interview.
Cybersecurity is not solely the responsibility of security teams. It is a shared responsibility across the entire software development lifecycle.
In my case, I did not execute any code or grant remote access to my computer.
I am currently preparing the messages, links, and other available evidence for reporting to the relevant platforms and authorities.
My intention in sharing this experience is not to accuse anyone without evidence.
Rather, I hope to raise awareness among fellow developers, particularly those who encounter international remote and freelance opportunities, so they can recognize potential warning signs and make informed decisions.
Have you ever encountered a similar situation during a technical interview?
Sharing your experience could help another developer avoid a potentially dangerous situation.
🌍 International Security Research and Official Advisories
Following this experience, I reviewed cybersecurity research documenting how similar techniques have been used to target software developers worldwide.
This threat has attracted attention not only from independent security researchers but also from major technology and cybersecurity organizations, including Microsoft, Atlassian, and Palo Alto Networks, as well as government cybersecurity agencies.
One particularly notable finding: According to an international security advisory published in September 2026, activities associated with WaterPlum / Contagious Interview reportedly resulted in the compromise of at least 30,000 devices across more than 100 countries, with more than 7,000 cryptocurrency wallets targeted and funds or credentials stolen.
These figures illustrate the potentially significant impact of organized cyberattack campaigns targeting software developers.
📚 Security Research and Reports I Reviewed
1. U.S. Department of Defense Cyber Crime Center (DC3) and FBI — International Joint Cybersecurity Advisory
September 18, 2026
This joint advisory involving security and intelligence agencies from the United States, Japan, Australia, and Germany examines how the threat actor known as WaterPlum, also associated with Contagious Interview, targets software developers through fraudulent job opportunities, online technical interviews, and projects containing malicious code.
2. Microsoft Security — Contagious Interview: Malware Delivered Through Fake Developer Job Interviews
March 11, 2026
Microsoft’s technical research examines how attackers use projects distributed through GitHub, GitLab, and Bitbucket to trick developers into executing malicious code.
The report discusses techniques involving npm packages, Visual Studio Code tasks, credential theft, and malware families such as OtterCookie and InvisibleFerret.
3. Atlassian — From Fake Interviews to Malicious Repositories: Disrupting Contagious Interview
September 21, 2026
This research from Atlassian, the company behind Bitbucket, is particularly relevant to my experience.
It describes how attackers can create convincing applications in public repositories and conceal a small amount of malicious code among thousands of lines of otherwise legitimate-looking source code.
4. Palo Alto Networks Unit 42 — Contagious Interview
October 9, 2024
Unit 42’s research examines the use of BeaverTail and InvisibleFerret malware in fraudulent recruitment campaigns.
The report explores how attackers impersonate recruiters, target software developers, and deploy malware capable of operating on Windows and macOS systems.
#CyberSecurity #ContagiousInterview #SoftwareDevelopment #RemoteWork #InfoSec
