IT

🎫 Что такое Pass-the-Ticket? Мы уже разобрали: 🔐 NTLM → Pass-the-Hash Теперь пришло время второй популярной техники в инфраструктурном пентесте — Pass-the-Ticket.

📌 Pass-the-Ticket (PtT) — это атака, при которой злоумышленник использует уже полученный Kerberos-билет, а не пароль пользователя.

Проще говоря: вместо кражи пароля атакующий "подкладывает" системе чужой билет Kerberos и получает доступ от имени этого пользователя. 🧠 Вспомним, как работает Kerberos. Когда пользователь успешно входит в домен:

Логин
        ↓
Проверка пароля
        ↓
Domain Controller
        ↓
Выдаётся Kerberos Ticket

Именно этот билет используется для доступа к ресурсам сети. 💀 Если злоумышленник сможет получить такой билет, пароль ему уже не понадобится. Он может использовать билет для аутентификации так, словно является настоящим владельцем учётной записи. 📌 Чем отличается Pass-the-Hash от Pass-the-Ticket? Pass-the-Hash 👉 используется NTLM-хеш. Pass-the-Ticket 👉 используется Kerberos Ticket. Обычно атака выглядит так:

Получение Kerberos Ticket
        ↓
Импорт билета
        ↓
Доступ к сервисам

🛠 Для работы с Kerberos-билетами часто используют: — Mimikatz — Rubeus — Impacket 🧠 Важно понимать:

Pass-the-Ticket — это не способ получить билет, а способ использовать уже полученный. Поэтому чаще всего сначала злоумышленник получает доступ к системе, извлекает Kerberos-билеты из памяти, а затем использует их для перемещения по инфраструктуре.

📌 Именно поэтому защита рабочих станций и серверов так важна. Если атакующий получает возможность читать память процессов с билетами Kerberos, это может стать отправной точкой для дальнейшего развития атаки. #infra #ad #kerberos #passtheticket

YC-фаундеры отвечают на вопрос «Что вы делаете?» — давайте посмотрим, насколько это понятно Интереса добавляет, что все эти стартапы — dev tools, т.е. продукты для разработчиков, а фаундеры должны говорить о проекте так, чтобы поняли даже не технари: Infisical (W23) — платформа с открытым исходным кодом для защиты цифровых идентичностей. Мы работаем с компаниями вроде NVIDIA, LG и Hugging Face, помогая им управлять секретами, сертификатами и другими чувствительными ресурсами в инфраструктуре. Ollama (W21) — мы упрощаем запуск агентов и помощников, используя открытые модели. Resend (W23) — API для email для разработчиков. Мы — Stripe для электронной почты. Recall (W20) — API для данных о разговорах. Мы помогаем разработчикам записывать, хранить и анализировать данные с видеоконференций, телефонных звонков и личных встреч. Greptile (W24) — делаем агентов, которые проверяют и тестируют пулл-реквесты с учётом контекста кодовой базы. Мы делаем это для компаний вроде NVIDIA и Coinbase, проверяя более трёх миллиардов строк кода в месяц, выявляя антипаттерны и ошибки. Firecrawl (S22) — API для работы с веб-данными, предназначенный для AI-агентов и разработчиков. Porter (S20) — платформа, которая управляет вычислительными мощностями для стартапов на любых облачных провайдерах. Mintlify (W22) — мы создаём умную, AI-powered документацию для крупного бизнеса (enterprise) и стартапов. Unsloth (S24) — мы предоставляем локальные LLM-ки и значительно упрощаем обучение моделей. RevenueCat (S18) — мы упрощаем in-app подписки (внутри мобильных приложений) и помогаем разработчикам зарабатывать больше денег. Если непонятно, но заинтересовало — это тоже хороший результат. А вот если совсем непонятно и неинтересно, то это уже проблема. Я плохо понял и не заинтересовался Unsloth и Ollama, а Infisical понял только в процессе перевода, на слух бы не выкупил. А вы? @y_everyday — рефлексируем об акселератор, создавший 100+ стартапов-единорогов 🤩

Как понять, нужен ли вашему продукту ИИ (часть 2) В прошлый раз мы рассмотрели подробно, в каких задачах хорошо себя показывают ML, LLM, RAG и ИИ-агенты — удобная сравнительная таблица на слайде 1. Но выбор решения должен исходить из стратегических вопросов. Разберем фреймворк, который помогает точно выбрать подходящую ИИ-технологию или инструмент для вашего контекста. ❌ Частые ошибки при поиске ИИ-решения для продукта: — Выбирать модель раньше, чем продумали работу с данными: какие данные есть, хватит ли их, где они лежат, как получить к ним доступ? Этот этап занимает много времени, и если не оценить заранее его трудоемкость, можно сильно сдвинуть сроки. — Считать, что любая ИИ-функция должна отвечать мгновенно. На самом деле далеко не всегда — например, классификацию пользователей достаточно проводить раз в месяц. Работа в реальном времени резко повышает стоимость решения, поэтому такой режим стоит использовать только там, где он действительно необходим. — Надеяться на решение комплексной задачи одним инструментом. Если загрузить весь объем данных в одну модель, то результат будет в большей или меньшей степени состоять из галлюцинаций. — Запустить и забыть. Модель на проде нужно дообучать и переобучать в случае применения к другим продуктам, даже в схожих контекстах. ✅ Этапы использования ИИ в продукте 1️⃣ Четко сформулируйте бизнес-задачу, которую хотите решить с помощью ИИ. Она должна быть: — актуальна и значима для компании (автоматизация, сокращение времени); — иметь измеримые последствия (деньги, время, ресурсы). Для отслеживания прогресса сразу стоит: — определить ключевую метрику; — нарисовать схему процесса As Is → To Be. 2️⃣ Переведите бизнес-задачу в задачу для ИИ. Классический ML — К какому типу ML-задач относится ваш кейс? — Что будет являться целевой переменной, что модель должна предсказывать? — В чем бизнес-смысл этого предсказания? — На каком этапе бизнес-процесса будет использоваться модельное решение? — Какие математические метрики будут проверять качество модели? Генеративные модели — Какой тип генеративной архитектуры вы используете — LLM (GPT-подобная), diffusion, VAE, GAN или гибрид? — Что именно должна генерировать модель и по каким правилам? — В чем бизнесовая ценность этой генерации? — На каком шаге пользовательского/операционного процесса запускается генерация? — Какими метриками будете мерить качество вывода? 3️⃣ Подготовить данные. — Какие данные планируется использовать для обучения модели? Какие ключевые признаки? — На какую дату признаки должны собираться? Будут ли к этой дате известны показания по всем признакам? — Требуются ли внешние источники данных? — Требуются ли дополнительные действия для сбора данных? — Есть ли ограничения по использованию данных/моделей? — Можно ли отправлять данные за контур компании в вендорское решение? — За какой период (срок наблюдения) собираются данные? — Все ли данные уже есть в промышленных системах, или потребуется дополнительное подключение? 4️⃣ Выберите режим для модели. — Как часто будет работать модель: Batch — раз в день/неделю/месяц. Online — в момент действия пользователя. — Как часто нужно делать предсказание? — Есть ли требования к скорости ответа? 5️⃣ Продумайте внедрение в продукт. — Как модель будет интегрирована в бизнес-процессы и существующую архитектуру? — Требуется ли API или встраивание в существующие сервисы? — Нужно ли менять интерфейсы или бизнес-логику продукта? — Кто отвечает за поддержку и обновление модели после внедрения? — Как будет организована обратная связь от пользователей для улучшения качества предсказания? 6️⃣ Запланируйте регулярный мониторинг. — Какие метрики качества будут отслеживаться? — Как будет происходить мониторинг деградации модели? — Кто отвечает за реакцию на падение качества? — Как часто планируется переобучение модели? — Есть ли процесс аварийного отключения модели и возврата к ручному процессу? — Как будут учитываться требования по безопасности и хранению данных в эксплуатации? 7️⃣ Постройте систему метрик (слайд 5). В ней важно учитывать: — продуктовые метрики — от менеджера продуктов и бизнеса; — ML-метрики — от дата-сайентиста; — метрики связи продукта с ML. Только после этого имеет смысл выбирать между классическим ML, LLM, RAG или агентной архитектурой. И иногда правильным ответом окажется вовсе не генеративный ИИ. По мотивам мастер-класса «Нужен ли вашему продукту искусственный интеллект?» Михаила Войтко на ProductSense’25 💙 VK 🖤 YouTube @productsense

Время измен — Мы верны Claude, — сказал стартапер — А если завтра Gemini станет лучше? — Не станет Ребята из одного нашего стартапа пол-весны вылизывали промпты под Claude, обвязали их костылями и гордились «глубокой интеграцией». Вышел ChatGPT 5.6 — половина нагороженного стала мешать. Пока отдирали — конкурент обогнал их на голом апи. Сейчас время королевской гонки и корона держится у модели в среднем 41 день. С точки зрения венчурного инвестора, это — катастрофа. А вот создателя продукта — чудо. Каждые полтора месяца ты получаешь либо более умный мозг либо тот же, но дешевле. Ни-фи-га не делая, просто меняя одну строчку в конфиге. Это как если бы ключевой сотрудник каждые 40 дней становился вдвое умнее или соглашался на вдвое меньшую зарплату. А ты бы еще выбирал между тремя такими. Поэтому «жениться» на модели — ошибка. Верность в этом браке наказывается. Лучшая стратегия — чемодан у двери. Вывод прост: не влюбляйся в модель — влюбляйся в возможность её бросить. Архитектура, где мозг меняется одной строчкой, сегодня стоит дороже самого мозга.

«Про то, как я оцифровал себя без ИИ, чтобы стать видеоблогером» Задача звучит как реклама нейросетей: не люблю камеру, нет времени на съёмку и монтаж, но хочу вести видеоблог. Автор пошёл ровно наоборот и генерацию через ИИ отверг сразу — крипово, ненадёжно и неуважительно к зрителю. Вместо этого сел писать кастомный движок на JavaScript поверх After Effects, который из текстового сценария с тегами собирает вертикальное видео с его аватаром, липсинком под буквы и слайдами. Первый прототип показал жене. Она посмотрела и сказала, что технологично, но персонаж крайне кринжовый и будет пугать зрителя. Аватар слишком глубоко провалился в зловещую долину. «То есть, это будто бы ты, но ненастоящий». Посмотрим, каким одним приёмом он вытащил себя из долины и во что это вылилось по просмотрам.

Опять же, походу надо обьяснить. 1. Никакой прямой связи между шутками в Хвиттере и саспендом домена может не быть. И вероятно ее нет. 2. Имидж и репутация работают так, что в какой-то момент, когда французская полиция/российское руководство/илон маск/черногорский оператор реестра/кто угодно другой имеют некие претензии к Телеграм, груз имиджа Дурова, совокупность публичного поведения аккаунтов и прочих коммуникаций — не перевешивают эти претензии. Проще говоря, мелочи перестают сходить с рук, а за крупное уже начинают дрючить. Коммуникации, пиар и имидж именно для того и нужны — чтобы создать себе такой образ, когда тебе и твоей платформе прощают огрехи. В свое время Фейсбук именно на этом просрал львиную долю своих технических новшеств, включая божественный Graph API (его закрыли после скандала с Кембридж Аналитикс). У Телеграм имидж отрицательный. Причем, в целом, 50% отрицательной репутации создано публичными коммуникациями и развязным стилем поведения основателя. И страдают от этого и платформа, и основатель, и те, кто на платформе обитает, завязывает на ней личные и деловые коммуникации и так далее.