1. Зловмисники зламують «бухгалтерські» сервера з програмою 1С Складно уявити собі підприємство або...
2. Зловмисники зламують «бухгалтерські» сервера з програмою 1С

Зловмисники зламують «бухгалтерські» сервера з програмою 1С

Складно уявити собі підприємство або фізична особа-підприємця, які, при здійсненні своєї господарської діяльності, не вдаються до використання засобів автоматизації фінансової діяльності або процесу управління підприємством в цілому. За великим рахунком, найпоширенішими інструментами бухгалтера є системи дистанційного банківського обслуговування (сфера відповідальності банку) і спеціальні програми, наприклад 1С. Останні, є дуже «інтимним» місцем, встановлюють на серверне обладнання, розміщене десь за межами своєї країни, надаючи віддалений доступ користувачам по RDP (!). Хто знає, той не дасть збрехати, що рівень критичності інформації, що обробляється на таких серверах з 1С, досить високий. Волею-неволею якраз ці активи і опинилися під прицілом зловмисників. Розуміючи, що шифрувальники-вимагачі (ransomware) в даному випадку якраз те, що потрібно, атакуючі вирішили атакувати сервера з 1С, шифрувати дані і вимагати за них викуп.

Але на цьому проблеми не закінчуються. Так як погані хакери - народ господарський, вони не могли допустити, щоб хоч якась частинка скомпрометованої інформації, яка виявилася в їх розпорядженні, пропадала даремно. Безумовно, якщо розглянути шахрайство в системах дистанційного банківського обслуговування, операторам таких бот-мереж як, наприклад, ZeuS, в першу чергу цікаві комп'ютери, на яких встановлено програмне забезпечення «клієнт-банк», так як з них можна вкрасти гроші і отримати вигоду. А що ж робити з зараженими комп'ютерами тих бухгалтерів, які тільки те й роблять, що працюють віддалено в 1С? Вихід був знайдений! Чому б скомпрометовані аутентифікаційні дані для доступу до сервера 1C по протоколу RDP, не передавати «партнерам» для точкової опрацювання по лінії шифрування і вимагання ?!

Приклади того як очима зловмисників виглядали які раніше не перспективні комп'ютери з доступом до 1С, а також, знімки екранів з заражених комп'ютерів в момент доступу до 1С по RDP, наведені на рис. 1-3.

Мал. 1

Мал. 2

Мал. 3

Але не всі можуть собі дозволити бот-мережу. Частина зловмисників направили свої «дослідження» на пошук серверів, які передбачають підключення по RDP, і почали підбирати аутентифікаційні дані для отримання доступу до останніх. Іншими словами - «брут-хизуватися».
Зовсім недавно в мережі почали з'являтися повідомлення про те, що дані 1С піддаються шифрування [1] , А для отримання інструкції / ключа для розшифровки слід звертатися за вказаною електронною поштою. З одного боку нічого технічно складного в подібних атаках немає, але, в той же час, методи і підходи зловмисників виявилися дієвими (зроблений упор на якість, а не на кількість).
Забігаючи наперед, відзначимо, що реалізація загрози є можливою у разі некоректного налаштування сервера, в частині, що стосується безпеки віддаленого RDP-доступу.
По одному з таких звернень ми провели базове вивчення файлів реєстрації подій (Event Logs) і змогли зробити висновок про те, що і як відбувалося. В першу чергу стало зрозуміло, що для організації підбору паролів зловмисники використовують розподілену інфраструктуру. У дослідженому нами випадку підбір логінів і паролів здійснювався 11 днів з 68 різних IP-адрес розташованих в 21 країнах світу. Перелік IP-адрес, з яких проводилася атака, відображений нижче.

94.23.170.170 45.32.83.236 89.184.84.84 195.154.209.174 190.10.9.246 212.83.168.145 193.34.8.158 178.22.50.250 109.237.89.107 46.175.191.254 104.45.28.180 96.11.19.194 12.139.34.20 97.65.80.4 94.136.45.239 46.98.123.93 74.208. 153.91 62.205.128.83 76.79.234.170 212.48.66.50 195.138.198.199 94.158.46.227 178.238.92.22 212.57.114.159 109.107.232.75 89.179.244.173 78.37.97.102 91.223.180.250 78.85.33.136 89.151.134.231 163.158.144.184 77.232.25.22 172.245.123.14 188.247 .66.213 92.253.126.26 134.249.149.96 176.36.19.10 5.53.117.49 113.160.199.25 74.208.112.162 83.110.216.111 80.82.64.117 91.218.19.12 85.238.100.202 64.38.204.98 61.182.72.16 185.28.110.35 199.189.254.245 179.111.212.254 37.152.8.236 39.109.19.1 37.122.210.243 91.243.29.89 195.70.37.67 211.141.150.55 198.74.113.208 217.73.91.183 24.97.22.154 195.175.104.78 81.176.239.250 14.147.145.218 78.63.234.219 93.75.39.135 190.10.8.29 5.134.114.154 103.24.92.220 136.243. 121.218 185.125.217.76 190.10.8.209

Загальна кількість логінів, до яких намагалися підібрати пароль, склало 973. ТОП-30 логінів і відповідне число спроб їх підбору, відображені нижче.

Admin 3424 Administrador 492 user2 161 Адмін 2900 administrateur 436 user3 157 Administrator 2544 user1 354 User1 157 administrator 2315 adm 336 manager 149 Адміністратор 2114 касир 298 Володимир 130 admin 921 guest 226 alina 113 user 780 бухгалтер 189 kassa 107 test 770 Таня 185 director 95 Administrateur1 522 User 168 sys 87 Administrateur 495 Наталя 164 test1 86

Основним інструментом для аналізу логів (а саме - Security.evtx) був «Log Parser 2.2». Для вивчення процесів, пов'язаних з віддаленим підключенням до сервера по RDP, ми звертали увагу на такі події:

• Successful User Account Login (EventID = 4624)
• Failed User Account Login (EventID = 4625)

Приклад одного з варіантів застосування «Log Parser 2.2» відображений нижче.

LogParser.exe -i: EVT -o: CSV "SELECT TimeGenerated, EXTRACT_TOKEN (Strings, 5, '|') AS TargetUserName, EXTRACT_TOKEN (Strings, 10, '|') AS LogonType, EXTRACT_TOKEN (Strings, 19, '|' ) AS IpAddress, EXTRACT_TOKEN (Strings, 20, '|') AS IpPort, EventID INTO 4625-query.txt FROM Security.evtx WHERE EventID = 4625 "

Якщо задіяти один з доступних в «Log Parser 2.2» способів відображення даних (-o: DATAGRID), отриманий результат буде мати такий вигляд (Рис. 4). Відзначимо, що з 31878 записів в балці Security.evtx, 30266 записів були присвячені події «Failed User Account Login» (що дуже яскраво характеризує проведену на сервер «брут-форс» атаку.).

Мал. 4

Внаслідок вдало підібраного пароля зловмисники здійснюють віддалений доступ до сервера і вибірково шифрують важливі дані, залишаючи «повідомлення» постраждалим (рис. 5-7).

Мал. 5

Мал. 6

Мал. 7

Деякі зловмисники виявляються настільки максималистами, що, крім зашифровування даних 1С, не упускають можливості встановити на сервер додаткове програмне забезпечення, скажімо, для автоматизованого пошуку вразливостей в двигунах різних сайтів (наприклад, WordPress). Ті, хто досліджував подібний інцидент з шифруванням баз даних 1С, ймовірно, дивувалися, чому на сервер з 1С додатково встановлюється Python (рис. 8-9)

Мал. 8

Мал. 9

Мета даної статті - звернути увагу на описану загрозу. В першу чергу, матеріал є релевантним для тих, чия «фінансова інформація» обробляється на віддалених серверах з RDP-доступом. Кілька рекомендацій, спрямованих на мінімізацію ймовірності реалізації загрози, а також - можливих негативних наслідків, наведені нижче.

1. Регулярне резервне копіювання даних.
2. Обмеження доступу до RDP за допомогою брандмауера: дозволити доступ тільки з конкретних IP-адрес / підмереж.
3. Використання RDP-шлюзів [2] .
4. Забезпечення доступу до термінального сервера за допомогою шифрованих тунелів (IPSec).
5. Використання механізму Network Level Authentication (NLA) [3] .
6. Ускладнення завдання підбору пароля за допомогою політики блокування облікового запису після введення певної кількості (3-5) невірних комбінацій логін-пароль.
7. Використання не типових назв облікових записів.
8. Зміна стандартного номера мережевого порту (3389 / tcp) на якому функціонує RDP, на нетиповий.
9. Регулярний моніторинг подій інформаційної безпеки.

Підрозділ реагування на інциденти CyS Centrum

Використані матеріали:
[1] https://forum.esetnod32.ru/forum35/topic12795/
[2] https: //security.berkeley.edu/resources/best-pract ...
[3] https: //technet.microsoft.com/en-us/library/cc7327 ...

Зловмисники зламують «бухгалтерські» сервера з програмою 1С

Складно уявити собі підприємство або фізична особа-підприємця, які, при здійсненні своєї господарської діяльності, не вдаються до використання засобів автоматизації фінансової діяльності або процесу управління підприємством в цілому. За великим рахунком, найпоширенішими інструментами бухгалтера є системи дистанційного банківського обслуговування (сфера відповідальності банку) і спеціальні програми, наприклад 1С. Останні, є дуже «інтимним» місцем, встановлюють на серверне обладнання, розміщене десь за межами своєї країни, надаючи віддалений доступ користувачам по RDP (!). Хто знає, той не дасть збрехати, що рівень критичності інформації, що обробляється на таких серверах з 1С, досить високий. Волею-неволею якраз ці активи і опинилися під прицілом зловмисників. Розуміючи, що шифрувальники-вимагачі (ransomware) в даному випадку якраз те, що потрібно, атакуючі вирішили атакувати сервера з 1С, шифрувати дані і вимагати за них викуп.

Але на цьому проблеми не закінчуються. Так як погані хакери - народ господарський, вони не могли допустити, щоб хоч якась частинка скомпрометованої інформації, яка виявилася в їх розпорядженні, пропадала даремно. Безумовно, якщо розглянути шахрайство в системах дистанційного банківського обслуговування, операторам таких бот-мереж як, наприклад, ZeuS, в першу чергу цікаві комп'ютери, на яких встановлено програмне забезпечення «клієнт-банк», так як з них можна вкрасти гроші і отримати вигоду. А що ж робити з зараженими комп'ютерами тих бухгалтерів, які тільки те й роблять, що працюють віддалено в 1С? Вихід був знайдений! Чому б скомпрометовані аутентифікаційні дані для доступу до сервера 1C по протоколу RDP, не передавати «партнерам» для точкової опрацювання по лінії шифрування і вимагання ?!

Приклади того як очима зловмисників виглядали які раніше не перспективні комп'ютери з доступом до 1С, а також, знімки екранів з заражених комп'ютерів в момент доступу до 1С по RDP, наведені на рис. 1-3.

Рис. 1

Рис. 2

Рис. 3

Але не всі можуть собі дозволити бот-мережу. Частина зловмисників направили свої «дослідження» на пошук серверів, які передбачають підключення по RDP, і почали підбирати аутентифікаційні дані для отримання доступу до останніх. Іншими словами - «брут-хизуватися».
Зовсім недавно в мережі почали з'являтися повідомлення про те, що дані 1С піддаються шифрування [1] , А для отримання інструкції / ключа для розшифровки слід звертатися за вказаною електронною поштою. З одного боку нічого технічно складного в подібних атаках немає, але, в той же час, методи і підходи зловмисників виявилися дієвими (зроблений упор на якість, а не на кількість).
Забігаючи наперед, відзначимо, що реалізація загрози є можливою у разі некоректного налаштування сервера, в частині, що стосується безпеки віддаленого RDP-доступу.
По одному з таких звернень ми провели базове вивчення файлів реєстрації подій (Event Logs) і змогли зробити висновок про те, що і як відбувалося. В першу чергу стало зрозуміло, що для організації підбору паролів зловмисники використовують розподілену інфраструктуру. У дослідженому нами випадку підбір логінів і паролів здійснювався 11 днів з 68 різних IP-адрес розташованих в 21 країнах світу. Перелік IP-адрес, з яких проводилася атака, відображений нижче.

94.23.170.170 45.32.83.236 89.184.84.84 195.154.209.174 190.10.9.246 212.83.168.145 193.34.8.158 178.22.50.250 109.237.89.107 46.175.191.254 104.45.28.180 96.11.19.194 12.139.34.20 97.65.80.4 94.136.45.239 46.98.123.93 74.208. 153.91 62.205.128.83 76.79.234.170 212.48.66.50 195.138.198.199 94.158.46.227 178.238.92.22 212.57.114.159 109.107.232.75 89.179.244.173 78.37.97.102 91.223.180.250 78.85.33.136 89.151.134.231 163.158.144.184 77.232.25.22 172.245.123.14 188.247 .66.213 92.253.126.26 134.249.149.96 176.36.19.10 5.53.117.49 113.160.199.25 74.208.112.162 83.110.216.111 80.82.64.117 91.218.19.12 85.238.100.202 64.38.204.98 61.182.72.16 185.28.110.35 199.189.254.245 179.111.212.254 37.152.8.236 39.109.19.1 37.122.210.243 91.243.29.89 195.70.37.67 211.141.150.55 198.74.113.208 217.73.91.183 24.97.22.154 195.175.104.78 81.176.239.250 14.147.145.218 78.63.234.219 93.75.39.135 190.10.8.29 5.134.114.154 103.24.92.220 136.243. 121.218 185.125.217.76 190.10.8.209

Загальна кількість логінів, до яких намагалися підібрати пароль, склало 973. ТОП-30 логінів і відповідне число спроб їх підбору, відображені нижче.

Admin 3424 Administrador 492 user2 161 Адмін 2900 administrateur 436 user3 157 Administrator 2544 user1 354 User1 157 administrator 2315 adm 336 manager 149 Адміністратор 2114 касир 298 Володимир 130 admin 921 guest 226 alina 113 user 780 бухгалтер 189 kassa 107 test 770 Таня 185 director 95 Administrateur1 522 User 168 sys 87 Administrateur 495 Наталя 164 test1 86

Основним інструментом для аналізу логів (а саме - Security.evtx) був «Log Parser 2.2». Для вивчення процесів, пов'язаних з віддаленим підключенням до сервера по RDP, ми звертали увагу на такі події:

• Successful User Account Login (EventID = 4624)
• Failed User Account Login (EventID = 4625)

Приклад одного з варіантів застосування «Log Parser 2.2» відображений нижче.

LogParser.exe -i: EVT -o: CSV "SELECT TimeGenerated, EXTRACT_TOKEN (Strings, 5, '|') AS TargetUserName, EXTRACT_TOKEN (Strings, 10, '|') AS LogonType, EXTRACT_TOKEN (Strings, 19, '|' ) AS IpAddress, EXTRACT_TOKEN (Strings, 20, '|') AS IpPort, EventID INTO 4625-query.txt FROM Security.evtx WHERE EventID = 4625 "

Якщо задіяти один з доступних в «Log Parser 2.2» способів відображення даних (-o: DATAGRID), отриманий результат буде мати такий вигляд (Рис. 4). Відзначимо, що з 31878 записів в балці Security.evtx, 30266 записів були присвячені події «Failed User Account Login» (що дуже яскраво характеризує проведену на сервер «брут-форс» атаку.).

Рис. 4

Внаслідок вдало підібраного пароля зловмисники здійснюють віддалений доступ до сервера і вибірково шифрують важливі дані, залишаючи «повідомлення» постраждалим (рис. 5-7).

Рис. 5

Рис. 6

Рис. 7

Деякі зловмисники виявляються настільки максималистами, що, крім зашифровування даних 1С, не упускають можливості встановити на сервер додаткове програмне забезпечення, скажімо, для автоматизованого пошуку вразливостей в двигунах різних сайтів (наприклад, WordPress). Ті, хто досліджував подібний інцидент з шифруванням баз даних 1С, ймовірно, дивувалися, чому на сервер з 1С додатково встановлюється Python (рис. 8-9)

Рис. 8

Рис. 9

Мета даної статті - звернути увагу на описану загрозу. В першу чергу, матеріал є релевантним для тих, чия «фінансова інформація» обробляється на віддалених серверах з RDP-доступом. Кілька рекомендацій, спрямованих на мінімізацію ймовірності реалізації загрози, а також - можливих негативних наслідків, наведені нижче.

1. Регулярне резервне копіювання даних.
2. Обмеження доступу до RDP за допомогою брандмауера: дозволити доступ тільки з конкретних IP-адрес / підмереж.
3. Використання RDP-шлюзів [2] .
4. Забезпечення доступу до термінального сервера за допомогою шифрованих тунелів (IPSec).
5. Використання механізму Network Level Authentication (NLA) [3] .
6. Ускладнення завдання підбору пароля за допомогою політики блокування облікового запису після введення певної кількості (3-5) невірних комбінацій логін-пароль.
7. Використання не типових назв облікових записів.
8. Зміна стандартного номера мережевого порту (3389 / tcp) на якому функціонує RDP, на нетиповий.
9. Регулярний моніторинг подій інформаційної безпеки.

Підрозділ реагування на інциденти CyS Centrum

Використані матеріали:
[1] https://forum.esetnod32.ru/forum35/topic12795/
[2] https: //security.berkeley.edu/resources/best-pract ...
[3] https: //technet.microsoft.com/en-us/library/cc7327 ...

Зловмисники зламують «бухгалтерські» сервера з програмою 1С

Складно уявити собі підприємство або фізична особа-підприємця, які, при здійсненні своєї господарської діяльності, не вдаються до використання засобів автоматизації фінансової діяльності або процесу управління підприємством в цілому. За великим рахунком, найпоширенішими інструментами бухгалтера є системи дистанційного банківського обслуговування (сфера відповідальності банку) і спеціальні програми, наприклад 1С. Останні, є дуже «інтимним» місцем, встановлюють на серверне обладнання, розміщене десь за межами своєї країни, надаючи віддалений доступ користувачам по RDP (!). Хто знає, той не дасть збрехати, що рівень критичності інформації, що обробляється на таких серверах з 1С, досить високий. Волею-неволею якраз ці активи і опинилися під прицілом зловмисників. Розуміючи, що шифрувальники-вимагачі (ransomware) в даному випадку якраз те, що потрібно, атакуючі вирішили атакувати сервера з 1С, шифрувати дані і вимагати за них викуп.

Але на цьому проблеми не закінчуються. Так як погані хакери - народ господарський, вони не могли допустити, щоб хоч якась частинка скомпрометованої інформації, яка виявилася в їх розпорядженні, пропадала даремно. Безумовно, якщо розглянути шахрайство в системах дистанційного банківського обслуговування, операторам таких бот-мереж як, наприклад, ZeuS, в першу чергу цікаві комп'ютери, на яких встановлено програмне забезпечення «клієнт-банк», так як з них можна вкрасти гроші і отримати вигоду. А що ж робити з зараженими комп'ютерами тих бухгалтерів, які тільки те й роблять, що працюють віддалено в 1С? Вихід був знайдений! Чому б скомпрометовані аутентифікаційні дані для доступу до сервера 1C по протоколу RDP, не передавати «партнерам» для точкової опрацювання по лінії шифрування і вимагання ?!

Приклади того як очима зловмисників виглядали які раніше не перспективні комп'ютери з доступом до 1С, а також, знімки екранів з заражених комп'ютерів в момент доступу до 1С по RDP, наведені на рис. 1-3.

Рис. 1

Рис. 2

Рис. 3

Але не всі можуть собі дозволити бот-мережу. Частина зловмисників направили свої «дослідження» на пошук серверів, які передбачають підключення по RDP, і почали підбирати аутентифікаційні дані для отримання доступу до останніх. Іншими словами - «брут-хизуватися».
Зовсім недавно в мережі почали з'являтися повідомлення про те, що дані 1С піддаються шифрування [1] , А для отримання інструкції / ключа для розшифровки слід звертатися за вказаною електронною поштою. З одного боку нічого технічно складного в подібних атаках немає, але, в той же час, методи і підходи зловмисників виявилися дієвими (зроблений упор на якість, а не на кількість).
Забігаючи наперед, відзначимо, що реалізація загрози є можливою у разі некоректного налаштування сервера, в частині, що стосується безпеки віддаленого RDP-доступу.
По одному з таких звернень ми провели базове вивчення файлів реєстрації подій (Event Logs) і змогли зробити висновок про те, що і як відбувалося. В першу чергу стало зрозуміло, що для організації підбору паролів зловмисники використовують розподілену інфраструктуру. У дослідженому нами випадку підбір логінів і паролів здійснювався 11 днів з 68 різних IP-адрес розташованих в 21 країнах світу. Перелік IP-адрес, з яких проводилася атака, відображений нижче.

94.23.170.170 45.32.83.236 89.184.84.84 195.154.209.174 190.10.9.246 212.83.168.145 193.34.8.158 178.22.50.250 109.237.89.107 46.175.191.254 104.45.28.180 96.11.19.194 12.139.34.20 97.65.80.4 94.136.45.239 46.98.123.93 74.208. 153.91 62.205.128.83 76.79.234.170 212.48.66.50 195.138.198.199 94.158.46.227 178.238.92.22 212.57.114.159 109.107.232.75 89.179.244.173 78.37.97.102 91.223.180.250 78.85.33.136 89.151.134.231 163.158.144.184 77.232.25.22 172.245.123.14 188.247 .66.213 92.253.126.26 134.249.149.96 176.36.19.10 5.53.117.49 113.160.199.25 74.208.112.162 83.110.216.111 80.82.64.117 91.218.19.12 85.238.100.202 64.38.204.98 61.182.72.16 185.28.110.35 199.189.254.245 179.111.212.254 37.152.8.236 39.109.19.1 37.122.210.243 91.243.29.89 195.70.37.67 211.141.150.55 198.74.113.208 217.73.91.183 24.97.22.154 195.175.104.78 81.176.239.250 14.147.145.218 78.63.234.219 93.75.39.135 190.10.8.29 5.134.114.154 103.24.92.220 136.243. 121.218 185.125.217.76 190.10.8.209

Загальна кількість логінів, до яких намагалися підібрати пароль, склало 973. ТОП-30 логінів і відповідне число спроб їх підбору, відображені нижче.

Admin 3424 Administrador 492 user2 161 Адмін 2900 administrateur 436 user3 157 Administrator 2544 user1 354 User1 157 administrator 2315 adm 336 manager 149 Адміністратор 2114 касир 298 Володимир 130 admin 921 guest 226 alina 113 user 780 бухгалтер 189 kassa 107 test 770 Таня 185 director 95 Administrateur1 522 User 168 sys 87 Administrateur 495 Наталя 164 test1 86

Основним інструментом для аналізу логів (а саме - Security.evtx) був «Log Parser 2.2». Для вивчення процесів, пов'язаних з віддаленим підключенням до сервера по RDP, ми звертали увагу на такі події:

• Successful User Account Login (EventID = 4624)
• Failed User Account Login (EventID = 4625)

Приклад одного з варіантів застосування «Log Parser 2.2» відображений нижче.

LogParser.exe -i: EVT -o: CSV "SELECT TimeGenerated, EXTRACT_TOKEN (Strings, 5, '|') AS TargetUserName, EXTRACT_TOKEN (Strings, 10, '|') AS LogonType, EXTRACT_TOKEN (Strings, 19, '|' ) AS IpAddress, EXTRACT_TOKEN (Strings, 20, '|') AS IpPort, EventID INTO 4625-query.txt FROM Security.evtx WHERE EventID = 4625 "

Якщо задіяти один з доступних в «Log Parser 2.2» способів відображення даних (-o: DATAGRID), отриманий результат буде мати такий вигляд (Рис. 4). Відзначимо, що з 31878 записів в балці Security.evtx, 30266 записів були присвячені події «Failed User Account Login» (що дуже яскраво характеризує проведену на сервер «брут-форс» атаку.).

Рис. 4

Внаслідок вдало підібраного пароля зловмисники здійснюють віддалений доступ до сервера і вибірково шифрують важливі дані, залишаючи «повідомлення» постраждалим (рис. 5-7).

Рис. 5

Рис. 6

Рис. 7

Деякі зловмисники виявляються настільки максималистами, що, крім зашифровування даних 1С, не упускають можливості встановити на сервер додаткове програмне забезпечення, скажімо, для автоматизованого пошуку вразливостей в двигунах різних сайтів (наприклад, WordPress). Ті, хто досліджував подібний інцидент з шифруванням баз даних 1С, ймовірно, дивувалися, чому на сервер з 1С додатково встановлюється Python (рис. 8-9)

Рис. 8

Рис. 9

Мета даної статті - звернути увагу на описану загрозу. В першу чергу, матеріал є релевантним для тих, чия «фінансова інформація» обробляється на віддалених серверах з RDP-доступом. Кілька рекомендацій, спрямованих на мінімізацію ймовірності реалізації загрози, а також - можливих негативних наслідків, наведені нижче.

1. Регулярне резервне копіювання даних.
2. Обмеження доступу до RDP за допомогою брандмауера: дозволити доступ тільки з конкретних IP-адрес / підмереж.
3. Використання RDP-шлюзів [2] .
4. Забезпечення доступу до термінального сервера за допомогою шифрованих тунелів (IPSec).
5. Використання механізму Network Level Authentication (NLA) [3] .
6. Ускладнення завдання підбору пароля за допомогою політики блокування облікового запису після введення певної кількості (3-5) невірних комбінацій логін-пароль.
7. Використання не типових назв облікових записів.
8. Зміна стандартного номера мережевого порту (3389 / tcp) на якому функціонує RDP, на нетиповий.
9. Регулярний моніторинг подій інформаційної безпеки.

Підрозділ реагування на інциденти CyS Centrum

Використані матеріали:
[1] https://forum.esetnod32.ru/forum35/topic12795/
[2] https: //security.berkeley.edu/resources/best-pract ...
[3] https: //technet.microsoft.com/en-us/library/cc7327 ...