Telegram statistics channel - @cybersecurefox

🔥 Оце поворот: Google тихо готує зміну, яка може перекроїти встановлення додатків на Android. Якщо коротко — sideloading вже не буде таким вільним, як ми звикли.Google запускає Accountability Layer — новий рівень контролю для всіх APK поза Google Play. Система перед установкою намагатиметься перевірити розробника і сам файл через інтернет, а якщо зв’язку немає — сипатиме попередженнями й ховатиме опцію «встановити без перевірки» десь у глибині. Мені здається, це крок до того, щоб навіть "завантажив з браузера й поставив" все одно проходило через фільтр Google 🧩.Паралельно заходить історія з обов’язковою верифікацією розробників: додатки від непідтверджених акаунтів просто не ставитимуться на сертифіковані девайси з Play Protect. Тобто навіть F-Droid та анонімні open‑source-проєкти можуть опинитись під загрозою 🚫. З одного боку, менше шкідливих програм, з іншого — більше контролю й залежності від однієї корпорації.Я от думаю: це нормальний компроміс заради безпеки, чи повзуче "закручування гайок" навколо Android‑екосистеми? Ви за максимальну свободу встановлення чи за жорсткий фільтр від Google? 🤔🔗 Докладніше:https://cybersecurefox.com/uk/android-accountability-layer-sideloading-bezpeka#android #google #безпека #приватність #технології #sideloadingCyberSecureFox

🔍 Натрапив на історію, яка дуже добре показує, як зараз виглядає справжній APT, а не «звичайний вірус».Фахівці Solar 4RAYS у російській держструктурі знайшли новий модульний бекдор ShadowRelay. Він не просто краде дані — це платформа, яка тихенько живе в мережі, довантажує потрібні шпигунські модулі й уміє керувати хостами, які взагалі не мають виходу в інтернет 🧩. Його пов’язують з Erudite Mogwai / Space Pirates, тобто класичний APT-рівень 🕵️.Зайшли банально: через вразливий Microsoft Exchange, не пропатчений від ProxyShell. Фішка ShadowRelay в тому, що його копії будують всередині мережі свій «ланцюжок»: один вузол із доступом в інтернет стає шлюзом, а решта працює вже в глибоких, ізольованих сегментах — саме там, де критична інфраструктура й чутливі дані 🏛️. Плагінів у цьому кейсі не знайшли, але по архітектурі видно, що розрахунок на дуже довгу гру.Мені здається, це ще один аргумент, чому просто «антивірус + фаєрвол» давно не варіант: потрібен нормальний EDR/XDR, моніторинг East–West-трафіку й жорстка гігієна того ж Exchange 🛡️. Як ви вважаєте, у нас уже достатньо серйозно ставляться до таких загроз, чи переважно реагують лише «після інциденту»? 🤔🔗 Докладніше:https://cybersecurefox.com/uk/shadowrelay-modulnyi-bekdor-apt-proxyshellCyberSecureFox

💻 Уявіть сервіс, який офіційно «тестує безпеку», а неофіційно вчить малвару ставати невидимою. Саме такою історією був AVCheck, і тепер його можливого адміністратора взяли в аеропорту Амстердама після втечі в ОАЕ ✈️.За даними нідерландської прокуратури, через фірми‑«оболонки» він продавав доступ до AVCheck розробникам шкідливого ПЗ. Цю історію вже вписали в операцію Endgame, яка б’є не лише по хакерах, а й по сервісах, що тримають кіберзлочинну екосистему ⚙️.По суті, AVCheck був великим сервісом обходу антивірусів: ти заливаєш зразок малварі й дивишся, що бачать AV та EDR 💸. Такі платформи вбудовані в модель crimeware-as-a-service і, як на мене, сильно знижують поріг входу — навіть «зелені» зловмисники отримують майже професійний рівень підготовки атак.Я б на місці бізнесу виходив із презумпції: якщо атака серйозна, її вже прогнали через щось на кшталт AVCheck 🛡️. Як ви ставитеся до підходу «вважати, що зловмисник уже всередині» — це адекватна обережність чи перебір у безпеці?🔗 Докладніше:https://cybersecurefox.com/uk/aresht-administratora-avcheck-operatsiya-endgame#кібербезпека #малварь #crimewareasaservice #endgame #avcheck #бізнес_та_безпекаCyberSecureFox

🚨 Здається, у нас вже фейкові злами стали новим видом інформаційної зброї. Натрапив на історію з месенджером Max — і вона дуже показова.Коротко: на DarkForums один «хакер» заявив, що вкрав 142 ГБ даних Max, розповів про «0-day уразливість», AWS, bcrypt і навіть пообіцяв викласти 5 ГБ через торрент. Але команда Max пройшлася по кожній деталі — і з’ясувалося, що опис інфри, формат «злитих» полів і навіть алгоритми взагалі не збігаються з тим, що вони реально використовують. В результаті автор «зливу» сам зізнався, що все вигадав. І ось що мене тут лякає найбільше ⚠️: навіть повністю фейковий витік запускає хвилю паніки, «експертних» постів і фішингових розсилок від псевдопідтримки з лінками «терміново змініть пароль». Тому я для себе тримаю просте правило: перевіряю лише офіційні канали, не клікаю по «інсайдах» з випадкових чатів, змінюю паролі й вмикаю 2FA прямо в додатку 🔐.Мені здається, далі таких історій буде тільки більше 🤷‍♂️ Як ви реагуєте на новини про «злами» — вірите з перших скринів у Telegram чи чекаєте офіційних підтверджень? 🤔🔗 Докладніше:https://cybersecurefox.com/uk/feikovyi-vzlom-messenger-max-fake-data-breach#кібератаки_витокиданих_безпекаонлайн_цифровагігієна_соціальнімережі_фішингCyberSecureFox

🚨 Сьогодні натрапив на історію, яка добре показує: у крипті можуть підвести не тільки біржі, а й чужі сервіси в ланцюгу. Ledger не зламали — зламали їхнього платіжного партнера Global-e, але наслідки все одно відчують користувачі.Фішка в тому, що через Global-e могли витекти ім’я, e-mail і адреса доставки людей, які купували Ledger. Самі seed-фрази та приватні ключі залишилися в безпеці, але тепер у злодіїв є суперцінний список: «ось e-mail, ось людина з апаратним гаманцем, швидше за все з криптою» 😬. Ідеальна база під таргетований фішинг, коли лист виглядає дуже правдоподібно.Мені здається, зараз критично: ніколи й нікому не диктувати свої 24 слова, уважно дивитися на домени листів і посилань та підтягнути захист пошти й акаунтів (2FA, окремий e-mail для крипти, без SMS) 🛡️🔐. Я для себе ще раз зафіксував правило: seed-фраза ніколи не вводиться онлайн, ні за яких умов 🧩. А ви як до цього ставитеся — вже розділяєте «крипто-пошту» й звичайну, чи все ще все в одному місці?🔗 Докладніше:https://cybersecurefox.com/uk/vytik-danykh-ledger-global-e-kriptovaliuta#кібербезпека_крипта_ledger_фішинг_цифровагігієна_приватністьCyberSecureFox

📺 Уявіть, ваш дешевий ТВ-бокс тихо працює в чужому ботнеті — а ви в цей час просто дивитеся серіальчик. Мені здається, історія з Kimwolf добре показує, наскільки ми недооцінюємо "розумні" пристрої вдома.Kimwolf — Android-ботнет, що вже підм'яв під себе майже 2 млн пристроїв — переважно дешеві ТВ-бокси. Він виріс із малварі Aisuru, яка світилась у DDoS-атаках до 29,7 Тбіт/с 🤯. Фішка в тому, що зловмисники йдуть через резидентні проксі-мережі й відкритий ADB — часто взагалі без пароля.Багато таких боксів приїжджають уже з вшитими проксі-SDK: гаджет одразу стає вузлом для чужого трафіку. Дослідники знайшли мільйони вразливих IP, а один із провайдерів, IPIDEA, був настільки “зручним”, що через нього легко заходили в локальні мережі ⚠️.Я для себе зробив висновок: будь-який «no-name» ТВ-бокс = ще один компʼютер у мережі, якому не варто сліпо довіряти. Мінімум безпеки — вимкнути ADB, почистити невідомі застосунки, оновити прошивку і по можливості посадити такі девайси в окрему Wi‑Fi / VLAN 🧩. А ви як ставитеся до дешевих Android-приставок — користуєтесь спокійно чи вже боїтеся підключати їх до домашнього роутера? 🤔🔗 Докладніше:https://cybersecurefox.com/uk/botnet-kimwolf-android-rezydentni-proxy-ddos#кібербезпека_android_iot_ботнети_приватність_ddosCyberSecureFox

🚨 Схоже, в мобільному Telegram є фіча, яка тихенько перетворилась на баг: один клік по «правильному» лінку — і ваша реальна IP-адреса вже у чужих логах. Без підтверджень, без «ви впевнені?», просто тихо у фоні.🧩 Фішка в тому, як клієнт обробляє посилання на MTProto‑proxy виду t.me/proxy?.... Щойно ви відкриваєте такий URL, Telegram автоматично конектиться до проксі, щоб «проверити, чи живий», і власник цього сервера одразу бачить ваш IP. І найцікавіше: лінк можна замаскувати під звичайний @username, тож в інтерфейсі все виглядає невинно.🕵️‍♂️ Для більшості це просто ще один ризик, але для журналістів, активістів чи тих, хто ховає локацію, — прямий шлях до деанонімізації. Я б радив уважніше дивитися, куди саме веде посилання, і тримати ввімкнений VPN / Tor 🛡️. Як вам така поведінка застосунку — нормальний компроміс заради зручності чи вже перебір, який вимагає реакції? 🤔🔗 Докладніше:https://cybersecurefox.com/uk/vrazlyvist-telegram-vitik-ip-adresy-mtproto-proxy#telegram_безпека_приватність_кібербезпека_ip_vpnCyberSecureFox

🧩 Натрапив на історію, після якої вже не так спокійно тиснеш «оновити» в браузері. Наприкінці 2025 Chrome-розширення Trust Wallet оновилося до версії 2.68 — і це оновлення виявилося трояном: з нього вкрали дані з 2 520 гаманців на суму близько $8,5 млн. Тобто люди все робили «правильно», але їх підловили саме на процесі апдейту.Фішка в тому, що зламали не користувачів, а ланцюжок постачання ПЗ: через зламаний GitHub-акаунт девелопера і API‑ключ Chrome Web Store зловмисники легально запушили шкідливу збірку. Це частина великої кампанії Shai-Hulud, де через сотні npm‑пакетів збирали секрети розробників (ключі, токени, паролі до CI/CD) і так дісталися до інфраструктури Trust Wallet. 🕵️‍♂️Мені здається, мораль тут проста й не дуже приємна: навіть «офіційне» оновлення може бути дверима для зливу ваших активів. Перевіряйте розширення, не переходьте за «форми для компенсацій» в Telegram, і нікому не давайте seed‑фразу — підтримка її ніколи не питає. 🤏 Як ви зараз захищаєте свої гаманці й акаунти розробника — є якась своя схема безпеки чи поки «якось воно буде»? 🔐🔗 Докладніше:https://cybersecurefox.com/uk/trust-wallet-shai-hulud-supply-chain-ataka#крипта_безпека_trustwallet_веб3_supplychainCyberSecureFox

🧨 Я щойно зарився в деталі останніх багів у n8n – і це виглядає як ідеальний вхід для атаки на всю інфру. Особливо якщо ви ганяєте через n8n LLM‑агентів, RAG‑ланцюги та підключаєте продові бази.У n8n знайшли одразу кілька критичних дірок, дві з них з оціночкою 10.0 по CVSS. Найжорсткіша — Ni8mare (CVE-2026-21858): дозволяє захопити інстанс без жодної авторизації через криву обробку Content-Type у вебхуках ⚠️. А тепер уявіть, що всередині лежать ваші API‑ключі, OAuth‑токени, доступи до хмар, CI/CD‑секрети – по суті, «ключі від усього продакшену» 🧩.Розробники вже закрили діри в релізах 1.121.3+ та 2.0.0+, але мені здається, головна помилка — тримати n8n голим у публічному інтернеті. Я б мінімум: оновився, заховав інстанс за VPN/reverse‑proxy 🛡️, увімкнув автентифікацію на всіх вебхуках/формах і переглянув/перегенерував секрети. Ви взагалі даєте n8n в інтернет напряму чи ховаєте за периметром? 🤔🔗 Докладніше:https://cybersecurefox.com/uk/krytychni-urazlyvosti-n8n-ni8mare-rce#кібербезпека_n8n_devops_ai-інфраструктура_автоматизація_інфобезпекаCyberSecureFox

🔥 В MongoDB зараз відбувається те, чого я завжди боявся: патч уже є, а експлойти по ньому — теж, і їх активно ганяють по всьому інтернету. Ситуація така, що один невчасно оновлений інстанс може відкрити двері в усю інфраструктуру.Мова про MongoBleed (CVE-2025-14847) — баг, який дозволяє неавтентифікованому атакеру не лише виконувати код на сервері, а й зливати шматки пам’яті MongoDB: логіни/паролі, AWS keys, токени доступу тощо 😬. Дослідники вже бачать реальні атаки, а в інтернеті світиться десятки тисяч вразливих інстансів, причому часто достатньо просто знати публічний IP.Мені здається, зараз "просто оновити" до 8.2.3 / 8.0.17 / 7.0.28 та інших патчених версій — мінімальна гігієна, але точно не фінал історії. Я би перевірив логи, перегенерував секрети, максимально закрив доступ до БД по мережі та підкрутив моніторинг (той же MongoBleed Detector виглядає корисно 🛡️). Цікаво, ви вже перевірили, чи немає у вас випадково "оголених" MongoDB у хмарі або на публічних IP? 🤔🔗 Докладніше:https://cybersecurefox.com/uk/mongobleed-cve-2025-14847-krytychna-rce-urazlyvist-mongodb#mongodb_mongo_bleed_безпека_кібербезпека_devops_інфраструктураCyberSecureFox