🐃 🧜🏽 🛄 Once at a pentest, or How to break everything with the help of a urologist and Roskomnadzor ☣️ 🐯 🤴🏽

This article is based on a very successful pentest, which was conducted by Group-IB specialists a couple of years ago: a story happened that claims to be a movie adaptation in Bollywood. Now, probably, the reader’s reaction will follow: “Oh, another PR article, again these are drawn, how good they are, do not forget to buy a pentest.” Well, on the one hand, it is. However, there are a number of reasons why this article appeared. I wanted to show what exactly pentesters are doing, how interesting and non-trivial this work can be, what amusing circumstances can develop on projects, and most importantly, to show live material with real examples.

To restore the balance of modesty in the world, after a while we will write about the pentest, which did not go. We show how well-established processes at a company can protect against a whole range of attacks, even well-prepared ones, simply because these processes exist and really work.

The customer from this article, too, everything was fine in general, at least better than 95% of the market in the Russian Federation, according to our feelings, but there were a number of minor nuances that formed a long chain of events, which led first to a long report on the work , and then to this article.

So, stock up on popcorn, and welcome to the detective. I ’m giving the floor to Pavel Suprunyuk , Technical Director of the Audit and Consulting Group-IB.

Part 1. Pochkin doctor

2018 year. There is a customer - a high-tech IT company, which itself serves many customers. He wants to get an answer to the question: is it possible, without any initial knowledge and access, working through the Internet, to gain administrator rights for an Active Directory domain? No social engineering is of interest ( eh, but in vain ), they are not specifically going to interfere with work, but they can accidentally reload a strange working server, for example. An additional task is to identify as many other attack vectors as possible with respect to the external perimeter. The company regularly conducts such tests, and now the deadline for a new test. The conditions are almost typical, adequate, understandable. Getting down.

There is a customer name - let it be "Company", with the main site www.company.ru. Of course, the customer is called differently, but in this article everything will be depersonalized.
I conduct network intelligence - I find out which addresses and domains are listed by the customer, draw a network diagram, how services are distributed to these addresses. I get the result: more than 4000 live IP addresses. I look through the domains in these networks: fortunately, the vast majority are networks intended for customer customers, and they do not formally interest us. The customer believes the same.

There remains one network with 256 addresses, for which by this moment there is already an understanding of the distribution of domains and subdomains by IP addresses, there is information about the scanned ports, which means you can look at the services for interesting ones with your eyes. In parallel, all kinds of scanners are launched at accessible IP addresses and separately - on websites.

There are a lot of services. This is usually a joy for the pentester and the anticipation of a quick victory, since the more services, the greater the field of attack and the easier it is to find an artifact. A quick look at the websites showed that most of them are web interfaces of the well-known products of large world companies that say that they are not happy with you. They ask for a username and password, from the threshold they shake the field for entering the second factor, they ask for a TLS client certificate or send them away to Microsoft ADFS. Some are simply unavailable from the Internet. For some, you obviously need to have a special paid client for three salaries or to know the exact URL to enter. We’ll omit another week of gradual discouragement in the process of trying to “break through” the software according to versions for known vulnerabilities, searching for hidden content in web paths and leaked accounts from third-party services such as LinkedIn,attempts to select passwords for them, as well as excavating vulnerabilities in self-described websites - by the way, according to statistics, this is the most promising vector of an external attack to date. Immediately I note the cinema gun, which subsequently fired.

So, there were two sites that stand out from hundreds of services. These sites had one thing in common: if you do not engage in meticulous network reconnaissance by domain, but look “on the front” for open ports or poison the vulnerability scanner over a known IP range, then these sites will go away from verification, they simply will not be visible without knowing the DNS name. Perhaps they were missed earlier, at least, and our automatic tools did not find problems in them, even if they were set directly on the resource.

By the way, about the fact that previously launched scanners were generally found. Let me remind you: for some people, “pentest” is tantamount to “automated scanning”. And the scanners on this project did not say anything. Well, Medium vulnerabilities showed the maximum (3 out of 5 in terms of danger): some service has a bad TLS certificate or outdated encryption algorithms, and most sites have Clickjacking. But on this you will not come to the goal. Probably, scanners would be more useful here, but let me remind you: the customer himself is able to purchase such programs and test himself with them, and judging by the dull results, he already checked it.

Back to the "abnormal" sites. The first is something like a local Wiki at a non-standard address, but let wiki.company [.] Ru be in this article. She also immediately requested a username and password, but already through NTLM in the browser. For the user, this looks like an ascetic window asking for a username and password. And this is bad practice.

. NTLM - . — Active Directory. company.ru, «» DNS-. , - , , - . — NTLM (, ?), «» , . , . — , . — . — , , . — pass-the-hash-. ADFS .

There is one bad feature of Microsoft products: even if you have not specifically published such NTLM, it will be in the default installation in OWA and Lync, at least.

By the way, the author of this article once in the same way accidentally blocked approximately 1000 accounts of employees of one large bank in just one hour and then had a somewhat pale appearance. The bank’s IT services were also pale, but everything ended well and adequately, we were even praised that we were the first to find this problem and provoked a quick and decisive correction.

The second site had the address "obviously-some-last name.company.ru". Found through Google, something like this on page 10. The design is beginning to mid 2000, and a respectable person looked from the main page, something like this:

Then he took a frame from "Dog’s Heart", but believe me, it was remotely similar, even the color scheme in similar colors. Let the site be called preobrazhensky.company.ru .

It was a personal site ... of a urologist. It became interesting what the site of the urologist does on the subdomain of a high-tech company. A quick dig at Google showed that this doctor was a co-founder of one of the legal entities of our customer and even contributed about 1000 rubles of registered capital. The site was probably created many years ago, and the customer’s server resources were used as hosting. The site has long lost relevance, but for some reason has been left working for a long time.

In terms of vulnerabilities, the website itself was safe. Looking ahead, I’ll say that it was a set of statics - simple html-pages with inserts of illustrations in the form of kidneys and bladders. "Breaking" such a site is useless.

But the web server under it was more interesting. Judging by the HTTP Server header, there was IIS 6.0, which means that Windows 2003 was used as an operating system. The scanner previously revealed that this particular website of the urologist, unlike other virtual hosts on the same web server, responded to the PROPFIND command, that is, WebDAV worked there. By the way, the scanner issued this information with the mark Info (in the language of scanner reports this is the lowest danger) - such things are usually simply skipped. In combination, this gave an interesting effect, which was revealed only after another digging into Google: a rare buffer overflow vulnerability associated with the Shadow Brokers set, namely CVE-2017-7269, which already had a ready exploit. In other words, it will be a disaster if you have Windows 2003 and WebDAV is running on IIS.Although working in production of Windows 2003 in 2018, this is in itself a disaster.

The exploit ended up in Metasploit and was immediately tested with a load that sent a DNS query to a controlled service - Burp Collaborator is traditionally used to trap DNS queries. Surprisingly, it worked the first time: a jerk was received in DNS. Then there was an attempt to create a back-end connection through port 80 (that is, a network connection from the server to the attacker, with access to cmd.exe on the victim host), but then a fiasco happened. The connection did not come, and after the third operation attempt, the site, along with all the entertaining pictures, disappeared for good.

Usually this is followed by a letter in the style of "customer, wake up, we have dropped everything." But we were told that the site has nothing to do with business processes and works there in general, it is not clear why, like the whole server, and that we can use this resource as we please.
After about a day, the site suddenly started working on its own. Having built a stand from WebDAV on IIS 6.0, I found that the default setting is to restart IIS workflows every 30 hours. That is, when the control exited from the shell code, the IIS workflow ended, then it restarted a couple of times itself and then went to rest for 30 hours.

Since the first time the bekconnect on tcp failed, I wrote off this problem to a closed port. That is, he suggested the presence of some firewall that did not let outgoing connections out. I started to run shell codes that sort through many tcp and udp ports, there was no effect. The reverse connection loads through http (s) from Metasploit - meterpreter / reverse_http (s) did not work. Suddenly, the connection to the same port 80 was established, but immediately broke. He wrote it off to the action of the still imaginary IPS, which did not like meterpreter traffic. In light of the fact that the connection of pure tcp to port 80 failed, but http did, I concluded that the http proxy was somehow configured in the system.

Tried even meterpreter through DNS (thanksd00kiefor his efforts, saved many projects), recalling the very first success, but he didn’t even work at the stand - the shell code was too voluminous for this vulnerability.

In reality, it looked like this: 3-4 attempts to attack within 5 minutes, then wait for 30 hours. And so for three weeks in a row. I even set up a reminder so as not to waste time. In addition, there was a difference in the behavior of the test and combat environments: for this vulnerability there were two similar exploits, one from Metasploit, the second from the Internet, redone from the version of Shadow Brokers. So, at the combat only Metasploit worked out, at the stand - only the second, which further complicated debugging and broke the brain.

In the end, the shell code proved to be effective, which downloaded an exe file from a given server via http and ran it on the target system. The shellcode was small enough to fit in, and at least it worked. Since the TCP server didn’t like traffic at all and http (s) was inspected for meterpreter, I decided that the fastest way was to download the exe file that contained the DNS-meterpreter through this shellcode.

Here again the problem arose: when downloading the exe-file and, as the attempts showed, no matter what, the download was interrupted. Again, some kind of protection device between my server and the urologist did not like http traffic with exe inside. It seemed like a “quick” solution to change the shellcode so that it obfuscated http traffic on the fly, so that abstract binary data was transferred instead of exe. Finally, the attack was successful, control came through the thin DNS channel:

It immediately became clear that I had the simplest rights to the IIS workflow that allow me to do nothing. This is how it looked on the Metasploit console:

All pentest methodologies strongly suggest that you need to increase the rights when gaining access. Usually I do not do this locally, since the very first access is considered simply as a network entry point, and compromising another machine on the same network is usually easier and faster than increasing privileges on an existing host. But this is not the case, since the DNS channel is very narrow and it will not allow traffic to roam.

Assuming that this server with Windows 2003 was not repaired from the well-known MS17-010 vulnerability, I am tunneling traffic to port 445 / TCP through the meterpreter DNS tunnel to localhost (yes, this is also possible) and trying to run a previously downloaded exe through the vulnerability. The attack works, I get a second connection, but with SYSTEM privileges.

Interestingly, the server was still trying to protect against MS17-010 - it had disabled vulnerable network services on the external interface. This really protects against attacks through the network, but the attack from within the localhost worked, since you cannot just take and quickly turn off SMB on localhost.

Next, new interesting details are revealed:

Having SYSTEM permissions, you can easily install back-connect via TCP. Obviously, the prohibition of direct TCP is exclusively an IIS limited user problem. Spoiler: IIS user traffic was somehow wrapped in the local ISA Proxy in both directions. How exactly this works is not reproduced.
I’m in a certain “DMZ” (and this is not an Active Directory domain, but WORKGROUP) - it sounds logical. But instead of the expected private (“gray”) IP address, I’m quite “white”, exactly the same as I attacked earlier. This means that the company is so old for the world of IPv4 addressing that it can afford to keep the DMZ zone at 128 “white” addresses without NAT according to the scheme, as was illustrated in the 2005 Cisco manuals.

Since the server is old, Mimikatz is guaranteed to work directly from memory:

I get the password of the local administrator, I tunnel RDP traffic through TCP and I go into a cozy desktop. Since you could do anything with the server, I delete the antivirus, I find that the server is accessible from the Internet only on TCP ports 80 and 443, and 443 was not busy. I raise the OpenVPN server to 443, add the NAT functions for my VPN traffic and get direct access to the DMZ network in unlimited form through my OpenVPN. It is noteworthy that ISA, with some non-disable IPS features, blocked my traffic with port scanning, for which it had to be replaced with a simpler and more flexible RRAS. So pentesters still sometimes have to administer everything.

An attentive reader will ask: “And what is the second site - a wiki with NTLM authentication, about which so much has been written?” About it further.

Part 2. Are you still not encrypting? Then we go to you already here

So, there is access to the DMZ network segment. You need to go to the domain administrator. The first thing that comes to mind is to automatically check for security the services inside the DMZ segment, all the more so since they are now much more open for research. A typical picture in a penetration test: the external perimeter is better protected than internal services, and when you get any access to a large infrastructure, it is much easier to get extended rights in a domain only because this domain begins to be accessible for tools, and secondly, there are always a couple of critical issues in the infrastructure for several thousand hosts.

I load scanners on DMZ through the OpenVPN tunnel, I wait. I open the report - again nothing serious, apparently someone walked in the same way to me. The next step is to examine how hosts communicate within the DMZ network. To do this, for starters, a regular Wireshark is launched with listening to broadcast requests, primarily ARP. ARP packages were collected all day. It turns out that several gateways are used in this segment. This will come in handy later. Gluing data on ARP request-response and port scan data, I found the output points of user traffic from within the local network in addition to those services that were previously known, such as web and mail.

Since at the moment I had no access to other systems and there was not a single account for corporate services, it was decided to fetch at least some account from the traffic using ARP Spoofing.

Cain & Abel was launched on the urologist's server. Taking into account the identified traffic flows, the most promising pairs were selected for the “man in the middle” attack, then by a short-term start for 5-10 minutes, with a timer to restart the server in case of “freezing”, some network traffic was received. As in the joke, there were two news:

Good: a lot of credentials were caught and the attack as a whole worked.
Bad: all credentials were from customers of the customer himself. Providing support services, customer’s specialists connected to customer services that did not always have traffic encryption configured.

As a result, I got hold of a lot of credentials that were useless in the context of the project, but definitely interesting as a demonstration of the danger of an attack. Border routers of large companies with telnet, forwarded debugging http-ports to internal CRM with all the data, direct access to RDP from Windows XP on the local network and other obscurantism. It turned out a sort of Supply Chain Compromise according to the MITRE matrix .

Also found a fun opportunity to collect emails from traffic, something like this. This is an example of a finished letter that went from our customer to his client's SMTP port, again, without encryption. A certain Andrei asks his namesake to resend the documentation, and it is laid out on a cloud disk with a username, password and link in one reply letter:

This is another reminder that you need to encrypt all services. It is not known who and when will read and apply specifically your data - a provider, a system administrator of another company, or such a pentester. I’m silent that many can simply intercept unencrypted traffic.

Despite the apparent success, this was not brought closer to the goal. It was possible, of course, to sit for a long time and get out valuable information, but not the fact that it would have appeared there, and the attack itself is very risky in terms of the integrity of the network.

After another digging in the services, an interesting idea came to my mind. There is such a utility called Responder (it is easy to find examples of applications by this name), which, by "poisoning" broadcast requests, provokes connections over a variety of protocols such as SMB, HTTP, LDAP, etc. in different ways, then each person who connects is asked to authenticate and adjusts so that authentication passes through NTLM and in a transparent mode for the victim. Most often, an attacker thus collects NetNTLMv2 handshakes and from them, according to the dictionary, quickly recovers user domain passwords. I wanted something similar here, but users were sitting “behind the wall”, or rather, they were separated by a firewall, and on the WEB they went through the Blue Coat proxy cluster.

Remember, I specified that the Active Directory domain name coincided with the "external" domain, that is, was company.ru? So, Windows, more precisely Internet Explorer (and Edge, and Chrome), allow the user to authenticate transparently in HTTP via NTLM, if they consider that the site is in some “Intranet Zone”. One of the signs of “Intranet” is a call to a “gray” IP address or a short DNS name, that is, without dots. Since a server with a “white” IP and DNS name preobrazhensky.company.ru was at its disposal, and domain machines usually get the Active Directory domain suffix via DHCP to simplify name entry, they just had to write preobrazhensky URL in the address barso that they find the right path to a compromised urologist server, not forgetting that it is now called "Intranet". That is, at the same time giving me the NTLM-handshake user without his knowledge. It remains to make client browsers think about the urgent need to access this server.

The wonderful utility Intercepter-NG came to the rescue (thanksIntercepter) It allowed you to change traffic on the go and worked perfectly on Windows 2003. There was even a separate functionality for modifying only JavaScript files in the traffic stream. It was planned a sort of massive Cross-Site Scripting.

Blue Coat proxies through which users accessed the global WEB periodically cached static content. By intercepting traffic, it was clear that they work around the clock, endlessly requesting frequently used statics to accelerate the display of content during peak hours. In addition, BlueCoat had a specific User-Agent, which clearly distinguished it from a living user.

Javascript was prepared, which with the help of Intercepter-NG at night spent an entire hour implementing each answer with JS files for Blue Coat. The script did the following:

Detected the current browser by User-Agent. If it was Internet Explorer, Edge or Chrome - it worked on.
Waited until the DOM of the page is formed.
I inserted an invisible picture with the src attribute of the preobrazhensky type into the DOM : 8080 / NNNNNNN.png, where NNN are arbitrary digits so that BlueCoat does not cache.
Set a global flag variable that the injection was made and that you no longer need to insert pictures.

The browser tried to load this picture, on port 8080 of the compromised server, it was waiting for the TCP tunnel to my laptop, where the same Responder was launched, which requires NTLM login from the browser.

Judging by the Responder logs, in the morning people came to work, turned on their workstations, then began to visit the urologist’s server en masse and invisibly, not forgetting to “merge” NTLM handshakes. Handshakes rained all day and clearly accumulated material for a notoriously successful password recovery attack. This is what the Responder logs looked like:

Massive secret visits to the urologist’s server by users

You probably already noticed that this whole story is built on the principle “everything was fine, but there was a bummer, then there was overcoming, and then everything came to success”. So, there was a bummer. Of the five hundred unique handshakes, not one was revealed. And this is taking into account the fact that even on a laptop with a dead processor, these NTLMv2 handshakes get over at the speed of several hundred million attempts per second.

I had to arm myself with password mutation techniques, a graphics card, a dictionary thicker and wait. After a long time, several accounts with passwords of the form “Q11111111 ... .1111111q” were opened, which suggests that all users were once forced to come up with a very long password with a different case of characters, which was supposed to be complicated. But you can’t just fail a seasoned user, and in this way he made it easier to remember. In total, about 5 pieces were opened, and only one of them had any valuable rights to the services.

Part 3. Roskomnadzor strikes back

So, the first domain accounts were received. If at this point you did not fall asleep from a long reading, you will probably remember that I mentioned a service that did not require a second authentication factor: this is a wiki with NTLM authentication. Of course, the first thing they did was enter. Digging into the internal knowledge base quickly brought results:

The company has a WiFi network with domain account authentication with access to a local network. With the current data set, this is already a working attack vector, but you need to go to the office with your feet and place yourself somewhere in the customer’s office.
, , … « » , . «» «» . , DMZ.

Of course, the “second factor” was immediately added to the compromised account as an application on my phone. There was a program that can either loudly send a push request to the phone with the “approve” / “disapprove” buttons, or silently show the OTP code on the screen for further independent input. Moreover, the first method was supposed to be the only correct instruction, but did not work, unlike the OTP method.

With the broken "second factor", I managed to log into Outlook Web Access mail and remotely access the Citrix Netscaler Gateway. In Outlook, a surprise was waiting in the mail:

In this rare shot you can see how Roskomnadzor helps pentesters.

These were the first months after the famous Telegram fan lock, when whole networks with thousands of addresses inexorably disappeared from access. It became clear why push didn’t work right away and why my “victim” didn’t sound the alarm because they started using her account in open hours.

Those who are familiar with Citrix Netscaler imagine that it is usually implemented in such a way that it is possible to convey to the user only a picture-interface, trying not to give him the tools to launch third-party applications and transfer data, in every possible way restricting actions through standard control shells. By my occupation, I only got 1C:

Having walked a bit on the 1C interface, I found that there are external processing modules there. They can be loaded from the interface, and they will be executed on the client or server, depending on the rights and settings.

I asked friends 1C programmers to create such processing that would take a string and execute it. In 1C, the launch of the process looks something like this (taken from the Internet). Agree, the syntax of 1C language strikes a Russian-speaking person with its immediacy?

The processing was perfectly executed, it turned out what Pentesters call the “shell” - Internet Explorer was launched through it.

Earlier, the address of the system was found in the mail, which allows you to order passes to the territory. I ordered a pass in case I have to use the attack vector via WiFi.

On the Internet, they say that in the customer’s office there was still a tasty free catering, but I still preferred to develop an attack through a remote site, it’s calmer.

AppLocker was activated on the application server with Citrix, but it was bypassed. The same Meterpreter was loaded and started via DNS, because the http (s) versions did not want to connect, and I did not know the internal proxy address then. By the way, from this moment on, the external pentest essentially turned into the internal one.

Part 4. Admin rights for users - this is bad, p-nyatnenko?

The first thing a Pentester does when he takes control of a domain user’s session is to collect all the information about the rights in the domain. There is such a utility BloodHound, which automatically allows you to download information about users, computers, security groups through the LDAP protocol from the domain controller, and information about which user has recently logged in and who is the local administrator through SMB.

A typical technique for capturing domain administrator privileges looks simplified like a cycle of monotonous actions:

We go to domain computers, where there are local administrator rights, based on already captured domain accounts.
Mimikatz , Kerberos NTLM , . lsass.exe . Windows 2012R2/Windows 8.1 .
, . . - .

“End of Cycle;” as 1C programmers would write here.

So, our user turned out to be a local administrator on just one host with Windows 7, whose name was the word "VDI", or "Virtual Desktop Infrastructure", personal virtual machines. Probably, the designer of the VDI service implied that since VDI is the user's personal operating system, let the user then change the software environment, as you like, anyway the host can be "reloaded". I also thought that, in general, the idea is good, I went to this personal VDI host and made a socket there:

I installed the OpenVPN client there, which made a tunnel through the Internet to my server. The client had to get through the very Blue Coat with domain authentication, but OpenVPN coped, as they say, out of the box.
Installed on VDI OpenSSH. Well, really, what is this Windows 7 without SSH?

This is how it looked alive. I remind you that all this has to be done through Citrix and 1C:

One of the techniques for promoting access to neighboring computers is checking the passwords of local administrators for a match. Here luck was waiting right away: the default local administrator's NTLM hash (which was suddenly called Administrator) approached neighboring VDI hosts, of which there were several hundred, through the pass-the-hash attack. Of course, the attack immediately went over them.

Then the VDI administrators shot themselves in the foot twice:
The first time VDI machines were not brought into action by LAPS, essentially saving the same local administrator password from an image that was massively deployed to VDI.
— , pass-the-hash . , , — .

Why SSH service on that Windows? Very simple: now the OpenSSH server not only provided a convenient interactive command shell without interfering with the user's work, but also a socks5 proxy on VDI. Through this socks, I connected via SMB and collected cached accounts from all these hundreds of VDI machines, then looked for the path to the domain administrator in the BloodHound graphs. With hundreds of hosts at my disposal, I found this way pretty quickly. Domain administrator rights have been obtained.

Here is a picture from the Internet, showing a similar search. The links show who the administrator is and who entered where.

By the way, remember the condition from the start of the project - "do not apply social engineering." So, I propose to ponder how much this whole Bollywood would be cut off with special effects, if one could nevertheless apply banal phishing. But personally I was very interested in doing all this. I hope you were interested in reading this. Of course, not every project looks so intriguing, but the work as a whole is very puzzling and does not stagnate.

Probably, someone will have a question: how to protect yourself? Even in this article, many techniques are described, Windows administrators do not even know about many of them. However, I propose to look at them from the standpoint of beaten principles and measures of information security:

do not use outdated software (remember Windows 2003 at the beginning?)
do not keep unnecessary systems turned on (why was the urologist's site?)
check user passwords for strength yourself (otherwise ~~soldiers ...~~ pentesters will do this )
Do not have the same passwords for different accounts (VDI compromise)
and other

Of course, it is very difficult to implement, but in the next article we will show in practice that this is quite possible.

Once at a pentest, or How to break everything with the help of a urologist and Roskomnadzor

Part 1. Pochkin doctor

Part 2. Are you still not encrypting? Then we go to you already here

Part 3. Roskomnadzor strikes back

Part 4. Admin rights for users - this is bad, p-nyatnenko?

More articles: