Теневые истории ,разная информация полезная и не очень

[Shadow]

Камера iPhone сможет криптографически подтверждать, что фотография настоящая

Apple готовит необычный механизм проверки подлинности фотографий. При создании снимка система сможет формировать криптографическое подтверждение происхождения изображения, позволяющее впоследствии проверить, действительно ли кадр был получен камерой iPhone и не подвергался незаметной цифровой подмене.

Механизм затрагивает сам процесс обработки снимка. Система должна подтверждать целостность программной среды, через которую проходят исходные данные с камеры, чтобы результат нельзя было незаметно заменить уже на этапе формирования фотографии. В итоге у изображения появляется своеобразное цифровое доказательство его происхождения, которое можно проверить независимо от того, где фотография впоследствии была опубликована.

Подобные технологии становятся особенно актуальными на фоне стремительного роста количества синтетических изображений. Вопрос постепенно меняется: вместо попыток определить по пикселям, была ли картинка сгенерирована или изменена, можно подтверждать происхождение настоящих фотографий непосредственно в момент нажатия на кнопку камеры.

Возможно, скоро главным признаком достоверности фотографии станет не то, насколько реалистично она выглядит, а наличие проверяемой цифровой истории её создания.

Как считаете, должны ли такие подтверждения подлинности со временем стать стандартной функцией камер всех смартфонов?

Поздравляю с изменением статуса

 

[Pomidoriys]

Поздравляю с изменением статуса

Привет дружище
Спасибо большое

 

[Pomidoriys]

КАК ОДИН ИНСТРУМЕНТ ПОПАДАЕТ И К ИССЛЕДОВАТЕЛЯМ, И К ПРЕСТУПНИКАМ

Граница между «хакерским» и обычным профессиональным инструментом гораздо менее очевидна, чем кажется со стороны. Сканеры, OSINT-платформы, средства автоматизации, анализаторы сетевого трафика и даже обычные языковые модели могут одновременно использовать специалисты по безопасности, пентестеры, исследователи и участники теневой среды. Технология зачастую одна - различаются задача, контекст и право на её выполнение.

Хороший пример - массовое сканирование интернета. Для исследователя оно позволяет находить неправильно настроенные системы, отслеживать распространённость уязвимого ПО и оценивать состояние инфраструктуры. Для злоумышленника те же данные потенциально превращаются в способ предварительного отбора интересующих систем. Сам процесс сбора технической информации при этом может выглядеть практически одинаково.

Таких пересечений много:
OSINT используют и журналисты, и расследователи, и мошенники
сетевые сканеры нужны администраторам, пентестерам и атакующим
инструменты анализа malware применяют как защитники, так и его разработчики
автоматизация помогает одновременно искать уязвимости и проверять защиту
публичные базы технических данных полезны обеим сторонам
ИИ способен ускорять обработку больших объёмов информации независимо от цели

Поэтому происхождение программы практически ничего не говорит о характере её использования. Инструмент, созданный исследовательской командой и опубликованный для защитников, может через несколько дней обсуждаться на теневых форумах. И наоборот: технологии, впервые замеченные в атаках, позднее подробно разбираются исследователями, воспроизводятся в контролируемой среде и используются для построения защиты.

Особенно заметно это стало с развитием open source. Раньше сложная технология могла оставаться внутри небольшой команды, а сегодня качественный инструмент быстро распространяется по всему миру. Вместе с преимуществами открытой разработки возникает неизбежный эффект: автор практически перестаёт контролировать, кто и зачем будет использовать его код.

ИИ усилил эту ситуацию, но не создал её. Языковые модели удобны для анализа информации, обработки кода, классификации больших массивов данных и автоматизации рутинных операций. Все эти задачи существуют по обе стороны границы. Новым стал прежде всего масштаб и скорость, с которыми часть такой работы теперь можно выполнять.

Из-за этого попытка разделить технологии на «хорошие» и «плохие» быстро ломается. Даже специализированный инструмент безопасности может использоваться против чужой инфраструктуры, а программа, обнаруженная в криминальной операции, способна стать ценным материалом для исследования защиты.

Поэтому понятие dual-use для кибербезопасности - не исключение, а практически базовое состояние отрасли. Один и тот же инструмент может лежать на компьютере исследователя, системного администратора и участника даркнет-форума. Разница начинается не в коде программы, а в том, какую задачу с её помощью решают, против какой системы и с чьего разрешения.

 

[Pomidoriys]

Хакеры всё чаще атакуют корабли через спутниковый интернет

Спутниковая связь постепенно становится новой точкой входа для атак на морские суда. По данным компании Cydome, в 2024 году устройства, связывающие корабли со спутниками, фигурировали примерно в 3% морских кибератак, а уже в 2025 году — в 22%. Причина проста: современные суда постоянно обмениваются данными с берегом, а через одну сеть могут быть связаны связь, навигация и различные бортовые системы.

Речь уже не только о теоретической угрозе. В августе нефтяной танкер VL Prosperity примерно на 30 часов потерял связь, а его экипаж столкнулся с нарушениями в работе систем. На этой неделе сообщалось ещё о двух атаках на нефтяные танкеры. Американские власти подключались к проверке того, не были ли затронуты критически важные компоненты судов.

Дополнительную проблему создаёт распространение Starlink и других спутниковых систем на кораблях. Экипаж получает быстрый интернет практически в любой точке моря, но одновременно появляется больше оборудования, соединяющего внутреннюю инфраструктуру судна с внешней сетью. Специалисты предупреждают, что современный корабль постепенно превращается в огромную плавающую компьютерную сеть, где успешная атака потенциально способна выйти далеко за пределы обычной кражи данных.

Чем технологичнее становится судоходство, тем реальнее сценарий, при котором чрезвычайная ситуация на корабле начинается не со шторма или поломки двигателя, а с кибератаки.

Представляли раньше, что обычный спутниковый интернет на корабле может стать точкой входа к его бортовым системам?

 

[Pomidoriys]

ПОЧЕМУ НЕКОТОРЫЕ КИБЕРПРЕСТУПНЫЕ СЕРВИСЫ НЕ НУЖДАЮТСЯ В ДАРКНЕТЕ

Привычная картина теневой инфраструктуры выглядит просто: если сервис связан с киберпреступностью, значит он должен прятаться где-нибудь в Tor. На практике значительная часть такой экосистемы существует в обычном интернете, мессенджерах, облачных сервисах и на легальной инфраструктуре. Dark web давно перестал быть обязательной технической средой для всего, что принято называть даркнетом.

Причина проста: скрытый сервис решает определённый набор задач, но одновременно создаёт ограничения. Пользователю требуется дополнительное ПО, соединение может быть медленнее, возникают сложности с доступностью, защитой от атак и масштабированием. Если конкретному сервису не требуется скрывать сам факт своего существования, преимущества обычного веба могут перевесить преимущества onion-инфраструктуры.

Поэтому разные части одной экосистемы могут быть разбросаны между совершенно разными средами:
публичный сайт используется как витрина
коммуникация переносится в мессенджеры
закрытые сообщества работают по приглашениям в обычном интернете
файлы размещаются на сторонней инфраструктуре
технические компоненты маскируются среди легального трафика
Tor остаётся только для отдельных чувствительных элементов
часть сервисов вообще никогда не получает onion-адреса

Получается важное разделение: скрытость ресурса и скрытость его назначения - не одно и то же. Сервис может быть технически доступен любому браузеру, но оставаться практически невидимым для постороннего человека из-за закрытой регистрации, отсутствия индексации, узкого круга пользователей или постоянно меняющихся точек входа.

Есть и ещё один фактор - маскировка среди обычной инфраструктуры. Отдельный скрытый сервер сам по себе является специфическим объектом. А небольшой компонент, работающий через массового провайдера или распространённый интернет-сервис, оказывается среди миллионов совершенно легальных клиентов. В некоторых моделях раствориться в обычном интернете полезнее, чем физически отделиться от него.

Из-за этого граница между clearnet и darknet стала значительно менее аккуратной. Один проект может одновременно использовать обычный сайт, закрытый форум, мессенджер, публичные облачные сервисы, криптовалютную инфраструктуру и onion-ресурс. Рассматривать только последний - значит видеть лишь один слой системы.

Это хорошо объясняет, почему закрытие конкретного darknet-ресурса далеко не всегда уничтожает существовавшую вокруг него сеть. Пользователи, контакты и вспомогательные сервисы могут находиться совершенно в других местах и пережить исчезновение основной точки входа.

Поэтому современный даркнет правильнее воспринимать не как отдельный «тёмный интернет», физически отрезанный от обычной сети. Это экосистема, которая свободно проходит через границу между открытой и скрытой инфраструктурой и использует каждую среду там, где она удобнее. Иногда самая интересная часть даркнета вообще находится не в даркнете.

 

[Pomidoriys]

Ошибка длительностью в миллисекунду привела к отмене более 2000 авиарейсов

В Великобритании раскрыли причину масштабного сбоя авиасообщения, произошедшего 8 сентября. Проблему вызвала программная ошибка, возникшая буквально в пределах одной миллисекунды в системе управления воздушным движением. Несмотря на столь короткий технический сбой, последствия растянулись на часы и затронули около 30% запланированных рейсов.

В результате более 2000 рейсов пришлось отменить, а множество других получили серьёзные задержки. Сам сбой быстро закончился, но авиационная система уже успела потерять нормальный ритм: самолёты и экипажи оказались не там, где должны были находиться, аэропортам пришлось менять расписание, а диспетчерам — постепенно восстанавливать поток воздушного движения.

История наглядно показывает, насколько сильно современная авиация зависит от программного обеспечения. Одна миллисекунда ошибки в критической системе способна запустить цепную реакцию на тысячи рейсов, даже если оборудование физически полностью исправно и никакой кибератаки не происходило.

Иногда для огромного транспортного хаоса не нужны хакеры, отключение электричества или поломка оборудования — достаточно одной крайне неудачной миллисекунды в коде.

Представляли, что настолько короткий программный сбой вообще способен отменить тысячи авиарейсов?

 

[Pomidoriys]

КАК ИССЛЕДОВАТЕЛИ ПОНИМАЮТ, ЧТО ДВА РАЗНЫХ ПРОЕКТА МОГУТ БЫТЬ СВЯЗАНЫ

Два сервиса могут называться совершенно по-разному, использовать разные домены, появиться с интервалом в несколько лет и публично никак друг друга не упоминать. Тем не менее исследователи иногда предполагают, что за ними стоит одна команда или связанные между собой люди. Такие выводы редко строятся на одной громкой находке - гораздо чаще связь складывается из множества слабых совпадений.

Само по себе совпадение почти всегда может иметь невинное объяснение. Два проекта используют одинаковую библиотеку - её могли просто скачать из одного источника. Похож дизайн - возможно, использован готовый шаблон. Совпадает время активности - в одном часовом поясе находятся миллионы людей. Ценность появляется тогда, когда несколько независимых признаков начинают указывать в одном направлении.

Сопоставлять могут самые разные слои:
особенности инфраструктуры и конфигураций
повторяющиеся фрагменты или архитектурные решения в коде
характерные ошибки и нестандартные настройки
график публикаций и технической активности
особенности языка, оформления и терминологии
пересечения криптовалютной инфраструктуры
миграцию пользователей и персонала между проектами
последовательность событий при закрытии и последующем запуске

Особенно интересны редкие совпадения. Использование популярной технологии почти ничего не значит. А вот одинаковая необычная конфигурация, повторившаяся в двух независимых проектах вместе с другими признаками, уже значительно интереснее. Исследователь фактически оценивает не само совпадение, а вероятность того, что оно возникло случайно.

При этом похожесть ещё не означает общего владельца. Один проект мог скопировать другой, приобрести его код, нанять бывшего разработчика или получить часть инфраструктуры после закрытия предшественника. Иногда связь действительно существует, но совсем не такая, какой кажется первоначально. Общее техническое происхождение и общая команда - разные утверждения.

Ситуация становится особенно показательной после исчезновения крупного проекта. Через некоторое время появляется новый сервис, а вместе с ним всплывают знакомые технические особенности, манера коммуникации или части старой экосистемы. Для наблюдателя это выглядит как возвращение прежней команды, хотя на практике возможны десятки сценариев - от полноценного перезапуска до использования чужого наследия.

Поэтому серьёзная атрибуция строится не по принципу «нашли одинаковую деталь - значит, это они». Чем важнее вывод, тем больше требуется независимых источников и тем осторожнее формулируется степень уверенности. Корреляция становится убедительной не тогда, когда найден самый эффектный признак, а когда разные типы данных начинают подтверждать одну и ту же картину.

В этом и заключается одна из интереснейших особенностей исследования даркнета: проекты способны полностью менять внешнюю оболочку, но избавиться от всей накопленной истории значительно сложнее. Иногда новую инфраструктуру выдаёт не один большой промах, а десяток мелочей, каждая из которых по отдельности практически ничего не значит.

 

[Pomidoriys]

Хакеры взломали хакеров: ShinyHunters проникли на сайт вымогателей Clop

В даркнете произошла довольно редкая разборка между двумя крупными киберпреступными группировками. ShinyHunters заявили, что взломали Tor-сайт группировки Clop, через который та публиковала похищенные у компаний данные и оказывала давление на своих жертв. Страницу дефейснули, а вместо привычного содержимого на ней появилось сообщение от атакующих.

Но простой заменой страницы дело, судя по заявлениям ShinyHunters, не ограничилось. Группировка утверждает, что смогла выгрузить данные с серверов Clop и похитить приватные ключи их onion-сервиса. Если это подтвердится, последствия могут оказаться значительно серьёзнее обычного дефейса: такие ключи являются важной частью идентичности скрытого сервиса в сети Tor. Clop при этом известна многолетними атаками на крупные компании и публикацией украденной информации для вымогательства.

Самое ироничное продолжение истории — ShinyHunters теперь угрожают шантажировать самих вымогателей похищенной у них информацией. Получилась почти зеркальная схема: группировка, зарабатывающая на компрометации чужой инфраструктуры и последующем давлении на жертв, внезапно сама оказалась по другую сторону такого сценария.

В даркнете начался тот редкий случай, когда вопрос «кто взломал?» приходится задавать дважды.

Как думаете, чем закончится ситуация, когда одна крупная хакерская группировка начинает вымогать деньги у другой?

 

[Pomidoriys]

ПОЧЕМУ РАЗРАБОТЧИК MALWARE И ЕГО ОПЕРАТОР - ДАВНО НЕ ОБЯЗАТЕЛЬНО ОДИН ЧЕЛОВЕК

Представление о создателе вредоносного ПО, который самостоятельно пишет код, ищет цели, разворачивает инфраструктуру и затем проводит операции, всё хуже соответствует современной киберпреступности. Сегодня разработка инструмента и его непосредственное использование могут существовать как два совершенно разных бизнеса.

Разработчику необязательно интересоваться конкретными жертвами. Его продуктом становится сам инструмент: кодовая база, обновления, панели управления, исправление ошибок и техническая поддержка. Оператору, наоборот, может быть совершенно неинтересно устройство программы изнутри - ему важны возможности, стабильность и пригодность под конкретные задачи.

Из-за этого вокруг malware появляется несколько отдельных ролей:
разработчики основной кодовой базы
специалисты по отдельным модулям
владельцы и администраторы инфраструктуры
операторы, непосредственно использующие инструмент
партнёры, работающие с определёнными целями
посредники, связывающие разные части экосистемы
техническая поддержка и обслуживание продукта

Хорошо это видно на модели Malware-as-a-Service. Разработчик фактически превращает вредоносное ПО в сервис: поддерживает продукт, выпускает новые версии и предоставляет его другим участникам. Один инструмент в результате может одновременно использоваться множеством независимых операторов, которые вообще не знают друг друга.

Это сильно усложняет вопрос авторства. Если один и тот же образец обнаруживают в атаках разных групп, совпадение инструмента ещё не означает общего исполнителя. Общий malware может говорить лишь об общем поставщике технологии, примерно так же, как использование одинакового легального ПО не делает две компании одной организацией.

Работает и обратная ситуация. Одна группа способна менять инструменты, покупать разработки у разных поставщиков или переходить на другой продукт после утечки исходников и появления средств обнаружения. Поэтому привязывать конкретного оператора исключительно к одному семейству malware становится всё менее надёжно.

Такое разделение труда выгодно ещё и экономически. Разработчику не требуется самостоятельно масштабировать операции, а оператору - годами поддерживать сложную кодовую базу. Каждый концентрируется на своей специализации, а готовые технологии начинают циркулировать между командами практически как отдельный товар.

Но вместе с эффективностью появляется зависимость. Утечка исходников, исчезновение разработчика, компрометация общей инфраструктуры или обнаруженная уязвимость способны одновременно ударить по множеству независимых клиентов. Чем популярнее становится один поставщик, тем больше внешне несвязанных операций оказываются технологически связаны через него.

Поэтому современный malware правильнее рассматривать не только как программу, а как часть отдельной производственной цепочки. Код может написать один человек, инфраструктуру предоставить второй, использовать инструмент третий, а конечную операцию организовать четвёртый. Вопрос «кто создал malware?» и вопрос «кто стоит за конкретной атакой?» сегодня всё чаще имеют совершенно разные ответы.