Фалшиви известия от платформи, платежни услуги и за авторски права до разработчици

Всеки разработчик, който публикува някъде, зависи от няколко профила: порталите за игри, регистъра на пакети, магазина за добавки, хостинга на кода, платежната услуга. Загубата на един от тях значи загуба на възможността да публикувате, а в най-лошия случай някой друг публикува от ваше име. Затова най-честата измама срещу разработчици изобщо не е предложение. Тя е известие, което изглежда като пратено от някоя от тези платформи и иска да действате веднага. Тази част от поредицата показва как изглеждат такива известия, случаите, които получихме, как се различава истинското от фалшивото и какво да направите, ако вече сте натиснали.

Първата част от поредицата описва предложенията за партньорство с такса напред и поддържа списъка на всички измамни съобщения, които сме получили. Тази част е за съобщенията, които искат вход, а не плащане.

#Какво получихме

Най-прекият случай дойде като публичен коментар под една от нашите игри в портал за игри. Профил с име като на служител на платформата пишеше, че версиите ни са скрити от модерирането и трябва да „завършим проверка на автора“ през съкратена връзка до 48 часа, с номер на заявка, който изглеждаше официален. Истинското модериране никога не става в публични коментари: платформите съобщават на разработчиците през таблото и с писма от собствения си домейн. Не отворихме връзката, изтрихме коментара и сигнализирахме профила през таблото.

По пощата получихме „необходимо е действие: обновете данните на бизнеса си, за да избегнете прекъсване“ от името на платежна услуга и „прегледайте потвърждаването на профила си“ от името на банка. Показаните имена бяха верни. Домейните на подателите бяха на несвързани страни. Нито едно от двете писма не би издържало поглед към заглавките.

Полезният обратен пример беше известие за изтичане на данни от услуга за фактуриране, която наистина ползваме. Изглеждаше тревожно, затова го проверихме по същия начин: SPF, DKIM и DMARC минаваха за собствения домейн на услугата, в писмото нямаше връзка за вход, а то само ни казваше да напишем адреса сами. За изтичането имаше и независими публикации. Писмото беше истинско. Проверката не обявява всичко за измама; тя различава двете.

#Схемите срещу разработчици

Регистри на пакети и магазини за добавки

Регистрите са ценна плячка, защото един откраднат профил може да изпрати вредна версия на всеки, който зависи от нея. През юли 2025 г. PyPI предупреди за писма от домейн, който се различаваше от истинския с една буква, с тема „[PyPI] Email verification“, които водеха към копие на страницата за вход. През август 2025 г. Mozilla предупреди авторите на добавки за писма, според които профилът им трябва да бъде обновен, за да продължат да ползват инструментите за разработчици. Съветът на Mozilla е добро общо правило: истинските писма идват само от домейните на самата фирма, минават SPF, DKIM и DMARC, а сайтът се отваря направо, не през връзката.

Хостинг на код и разрешения през OAuth

Най-хитрата разновидност изобщо не иска парола. През март 2025 г. нападатели отвориха фалшиви задачи „предупреждение за сигурност“ в близо 12 000 хранилища в GitHub, така че истинските известия на GitHub сами ги доставиха по пощата. Връзката водеше към истинска страница на GitHub за разрешение на приложение, наречено „gitsecurityapp“, което искаше пълен достъп до хранилищата, работните процеси и правото да трие хранилища. Ако го одобрите, предавате токен, без да сте написали парола. Нито една платформа не иска да разрешите чуждо приложение, за да „защитите“ профила си.

Известия за авторски права и правила

„Получихме DMCA известие относно профила ви“, „обявата ви може да нарушава правилата на общността“, „отговорете до 24 часа“. Malwarebytes описа такава кампания през ноември 2025 г., която водеше към фалшива страница за вход. Истинското известие по американския закон за авторското право има шест задължителни части, изброени в 17 U.S.C. 512(c)(3): подпис, произведението, за което се твърди нарушение, материалът и къде се намира, данни за връзка с подателя, декларация за добросъвестност и декларация под страх от наказание за лъжесвидетелстване, че подателят има право да действа. Писмо с бутон вместо тези части не е известие. Платформите показват действията си и в таблото.

Платежни услуги

„Плащането е задържано“, „потвърдете самоличността си“, „изплащанията ви са спрени“. Payoneer пише на страницата си за фишинг, че никога не иска номер на карта или парола по имейл или с кратко съобщение, и същото важи за всяка сериозна платежна услуга. Тези писма често идват с прикачен файл, което е втора причина да не ги отваряте.

#Как да проверите едно известие

1. Отворете оригинала на писмото и прочетете резултатите от удостоверяването. Заглавката Authentication-Results показва дали SPF, DKIM и DMARC са минали и за кой домейн. Домейнът трябва да е собственият домейн на платформата.
2. Сравнете домейна буква по буква. Една буква, тире, допълнителна дума като „support“ или „verify“ или различно окончание стигат, за да е чужд.
3. Отворете платформата сами. Напишете адреса или използвайте отметка, влезте и вижте таблото, известията и страницата за сигурност на профила. Истинският проблем е там.
4. Прочетете разрешенията на всяка страница за одобрение. Ако стъпка „за сигурност“ иска да дадете на приложение права върху хранилища, работни процеси или изтриване, затворете я.
5. Вижте накъде води връзката, без да я отваряте. Задръжте мишката над нея или я копирайте като текст. Съкратената връзка нарочно скрива целта си.

From: "Add-ons Team" <noreply@addons-support.example>
Authentication-Results: mx.example.net;
  spf=pass smtp.mailfrom=addons-support.example;
  dkim=pass header.d=addons-support.example;
  dmarc=pass header.from=addons-support.example

В примера по-горе всичко минава, а писмото пак е фалшиво: домейнът не е на платформата. Удостоверяването доказва откъде е дошло писмото, не кой стои зад него.

#Ако вече сте натиснали

• Сменете паролата на профила от истинския сайт и излезте от всички други сесии.
• Отнемете непознатите приложения с OAuth и личните токени за достъп и създайте нови там, където ви трябват.
• Прегледайте историята на сигурността, наскоро публикуваните версии, новите работни процеси в хранилищата и новите gist файлове.
• Ако сте въвели данни на карта, обадете се на банката и блокирайте картата.
• Уведомете платформата през официалната ѝ поддръжка или форма за сигнал и запазете съобщението за тях.

Ключовете за достъп (passkeys) и хардуерните ключове помагат много, защото работят само на истинския домейн: копието на страницата за вход не може да ги използва. Целият навик за проверка, заедно с филтрите, е описан в последната част от поредицата. За страната на сайта на същия проблем добър спътник е статията ни за основите на сигурността на уеб приложенията.

#Списък за проверка

• Иска ли писмото или коментарът да действам през неговата връзка?
• Има ли срок от 24 или 48 часа?
• Домейнът на подателя точно собственият на платформата ли е и минават ли SPF, DKIM и DMARC за него?
• Виждам ли същото известие в таблото, когато отворя сайта сам?
• Иска ли страницата за одобрение повече права, отколкото задачата изисква?
• Има ли известието за авторски права шестте части, които законът изисква?

#Често задавани въпроси

Може ли измама да дойде през истинските известия на платформата?

Да. Ако някой отвори задача, напише коментар или прати съобщение в платформата, истинското ѝ известие по пощата ще достави текста. Писмото е истинско; съдържанието не е от платформата. Преценявайте връзката и искането, не плика.

Какво да направя с фалшив коментар под моя игра или проект?

Не отваряйте връзката. Изтрийте или скрийте коментара, ако можете, сигнализирайте профила през функцията за сигнал на платформата и, ако тя има контакт за поддръжка, им съобщете за представянето за служител.

Винаги ли е фалшиво DMCA известие, което го няма в таблото?

Не винаги: някои известия се пращат направо на разработчика. Истинското пак посочва произведението, материала и подател, с когото може да се свържете, и съдържа задължителните декларации. То никога не изисква паролата ви.

#Източници

• Блог на Mozilla Add-ons: засечена фишинг кампания (на английски)
• Блог на PyPI: фишинг атака (на английски)
• BleepingComputer: фалшиви предупреждения за сигурност в GitHub (на английски)
• Malwarebytes: фалшиви известия за авторски права (на английски)
• 17 U.S. Code 512, Cornell Legal Information Institute (на английски)
• Payoneer: как да разпознаете фишинг (на английски)
• RFC 7489: DMARC (на английски)