This article is based on a very successful pentest conducted by Group-IB specialists a couple of years ago: there was a story that claims to be filmed in Bollywood. Now, probably, the reader's reaction will follow: "Oh, another PR article, again these are drawn, how good they are, don't forget to buy a pentest." Well, on the one hand, it is. However, there are a number of other reasons why this article appeared. I wanted to show what exactly pentesters do, how interesting and non-trivial this work can be, what funny circumstances can develop on projects, and most importantly, to show live material with real examples.
In order to restore the balance of modesty in the world, after a while we will write about the pentest, which did not work. We will show how well-established processes in 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 was also excellent in general, at least better than 95% of the market in the Russian Federation, according to our feelings, but there were a number of small nuances that formed into a long chain of events, which first led to a long report on the work and then to this article.
So, stock up on popcorn, and welcome to the detective. Word - Pavel Suprunyuk, technical manager of the “Audit and Consulting” division of Group-IB.
Part 1. Pochkin Doctor
2018 year. There is a customer - a high-tech IT company that itself serves many clients. Wants to get an answer to the question: is it possible, without any initial knowledge and access, working via the Internet, to get the rights of an Active Directory domain administrator? No social engineering is of interest (), they are not going to interfere with the work on purpose, but they can accidentally re-upload a strangely working server, for example. An additional task is to identify as many other attack vectors as possible in relation to the outer perimeter. The company regularly conducts such tests, and now the deadline for a new test has come. Conditions are almost typical, adequate, understandable. Let's get started.
There is a name of the customer - let it be "Company", with the main site . Of course, the customer is called differently, but in this article everything will be depersonalized.
I conduct network reconnaissance - I find out which addresses and domains are registered with 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 customers of the customer, and we are not formally interested in them. The client thinks the same.
There remains one network for 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 scanned ports, which means that you can look at services with your eyes for interesting ones. In parallel, all kinds of scanners are launched for available IP addresses and separately for websites.
There are a lot of services. This is usually a joy for a pentester and an anticipation of a quick victory, since the more services, the more the field for 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 well-known products of large global companies that pretend to say that they are not happy with you. They ask for a login and password, shake the field for entering the second factor from the threshold, ask for a TLS client certificate, or send it away to Microsoft ADFS. Some are simply not available from the internet. For some, you obviously need to have a special paid client for three salaries or know the exact URL to enter. Let's skip another week of gradual discouragement in the process of trying to “break through” the software for known vulnerabilities, searching for hidden content in web paths and leaked accounts from third-party services like LinkedIn, trying to guess passwords using them, as well as excavating vulnerabilities in self-written websites By the way, according to statistics, this is the most promising vector of an external attack today. I will immediately note that cinematic 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 domains, but “head-on” look for open ports or poison a vulnerability scanner using a known IP range, then these sites will evade verification, they simply will not be visible without knowing the DNS name. Perhaps they were missed before, 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 what the previously launched scanners found in general. 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 severity): on some service a bad TLS certificate or outdated encryption algorithms, and on most sites Clickjacking. But this will not reach the goal. Perhaps 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 has already checked.
Let's return to the "anomalous" sites. The first is something like a local Wiki at a non-standard address, but in this article let it be wiki.company[.]ru. She also immediately asked for a username and password, but 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.
A small remark. NTLM in websites on the perimeter is bad for a number of reasons. The first reason is that the Active Directory domain name is being exposed. In our example, it also turned out to be company.ru, as well as the “external” DNS name. Knowing this, it is possible to qualitatively prepare something malicious so that it is executed only on the organization's domain machine, and not in some sandbox. Secondly, authentication goes directly through the domain controller via NTLM (surprise, right?), With all the features of the “internal” network policies, including blocking accounts from exceeding the number of password entry attempts. If an attacker recognizes logins, he will sort out passwords for them. If the account is configured to block the wrong password entry, it will work and the account will be blocked. Third, it is impossible to add a second factor to such authentication. If any of the readers still knows how - please let me know, it's really interesting. Fourth, vulnerability to pass-the-hash attacks. ADFS was invented, among other things, to protect against all this.
There is one bad thing about Microsoft products: even if you did not specifically publish such NTLM, it will be in the default installation in OWA and Lync, at least.
By the way, the author of this article once accidentally blocked about 1000 accounts of employees of one large bank in just one hour in the same way and then looked somewhat pale. The bank's IT services were also pale, but everything ended well and adequately, we were even praised for being the first to find this problem and instigated a quick and decisive fix.
The second site had the address “obviously-some-surname.company.ru”. Found through Google, something like this on the 10th page. The design was from the early to mid-XNUMXs, and a respectable person was looking from the main page, something like this:
Then I took a frame from Heart of a Dog, but believe me, it was remotely similar, even the color scheme was in similar tones. Let the site be called preobrazhensky.company.ru.
It was a personal site ... urologist. It became interesting what the urologist's website is doing on the subdomain of a high-tech company. A cursory Google dig showed that this doctor was a co-founder of one of our customer's legal entities and even contributed about 1000 rubles of authorized capital. Probably, the site was created many years ago, and the customer's server resources were used as hosting. The site has long lost its relevance, but for some reason it was left working for a long time.
In terms of vulnerabilities, the website itself was safe. Looking ahead, I will 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 header HTTP Server, there was IIS 6.0, which means that Windows 2003 was used as the operating system. The scanner previously revealed that this particular urologist website, unlike other virtual hosts on the same web server, responded to the PROPFIND command, meaning WebDAV was running there. By the way, the scanner gave out this information with the Info mark (in the language of scanner reports, this is the lowest danger) - such things are usually simply skipped. In combination, this had an interesting effect, which was only discovered after another Google digging: a rare buffer overflow vulnerability associated with the Shadow Brokers suite, namely CVE-2017-7269, which already had a ready exploit. In other words, there will be trouble if you have Windows 2003 and WebDAV is running on IIS. Although working in production Windows 2003 in 2018 is a disaster in itself.
The exploit ended up in Metasploit and was immediately tested with a load that sent a DNS request to a controlled service - traditionally used by Burp Collaborator to catch DNS requests. Surprisingly, it worked the first time: a rebuff was received in the DNS. Then there was an attempt to create a backconnect 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 attempt to operate the site, along with all the entertaining pictures, disappeared forever.
Usually this is followed by a letter in the style of "customer, wake up, we dropped everything." But we were told that the site has nothing to do with business processes and it works there for no reason at all, like the entire server, and that we can use this resource as we please.
About a day later, the site suddenly started working by itself. After building a WebDAV bench on IIS 6.0, I found that the default setting is to restart IIS worker processes every 30 hours. That is, when control exited the shellcode, the IIS worker process ended, then it restarted itself a couple of times and then went to rest for 30 hours.
Since the first time the backconnect to tcp failed, I attributed this problem to a closed port. That is, he assumed the presence of some kind of firewall that did not allow outgoing connections to go outside. I started running shellcodes that sort through a lot of tcp- and udp-ports, there was no effect. Reverse connection loads via http(s) from Metasploit - meterpreter/reverse_http(s) did not work. Suddenly, the connection to the same port 80 was established, but immediately broke off. I attributed this to the action of the still imaginary IPS, which did not like meterpreter traffic. In light of the fact that a pure tcp connection to port 80 did not pass, but http did, I concluded that an http proxy was somehow configured in the system.
Tried even meterpreter via DNS (thanks for his efforts, saved many projects), recalling the very first success, but it did not even work on the bench - the shellcode was too voluminous for this vulnerability.
In reality, it looked like this: 3-4 attack attempts within 5 minutes, then waiting for 30 hours. And so three weeks in a row. I even set up a reminder so as not to waste time. Additionally, there was a difference in the behavior of the test and production environments: there were two similar exploits for this vulnerability, one from Metasploit, the second from the Internet, remade from the version of Shadow Brokers. So, only Metasploit worked out on the battlefield, only the second one worked on the stand, which further complicated debugging and broke the brain.
In the end, the shellcode proved to be effective, which downloaded an exe file from a given server via http and launched it on the target system. The shellcode was small enough to fit through, and at least it worked. Since the server did not like TCP traffic at all and http (s) was inspected for the presence of meterpreter, I decided that the fastest way was to download the exe file that contained the DNS-meterpreter through this shellcode.
Here again a problem arose: when downloading an exe-file, and, as attempts showed, no matter which one, the download was interrupted. Again, some security device between my server and the urologist did not like the http traffic with the exe inside. It seemed like a "quick" solution to change the shellcode so that it would obfuscate http traffic on the fly, so that abstract binary data was transmitted instead of exe. Finally, the attack was successful, control was received through a thin DNS channel:
It immediately became clear that I have the simplest rights of the IIS worker process, which allow me to do nothing. This is how it looked on the Metasploit console:
Any pentest methodologies strongly suggest that you need to elevate rights when gaining access. I usually don't do this locally, as the very first access is treated simply as a network entry point, and compromising another machine on the same network is usually easier and faster than escalating privileges on an existing host. But this is not the case here, 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 famous MS17-010 vulnerability, I tunnel traffic to port 445/TCP through the meterpreter DNS tunnel to localhost (yes, this is also possible) and try to run the previously uploaded exe through the vulnerability. The attack works, I get a second connection, but with SYSTEM rights.
Interestingly, they still tried to protect the server from MS17-010 - it had vulnerable network services disabled on the external interface. This does protect against network attacks, but attacking localhost "from the inside" worked because you can't just quickly disable SMB on localhost.
Here are some interesting new details:
- Having SYSTEM rights, you can easily establish a backconnect via TCP. Obviously, the ban on direct TCP is solely a problem for the limited user of IIS. Spoiler: IIS user traffic was somehow wrapped in the local ISA Proxy in both directions. How exactly it works, did not reproduce.
- I'm in some kind of "DMZ" (and this is not an Active Directory domain, but a WORKGROUP) - it sounds logical. But instead of the expected private (“gray”) IP address, I have a completely “white” one, exactly the same one that I attacked earlier. This means that the company is so old for the world of IPv4 addressing that it can afford to keep a DMZ zone for 128 "white" addresses without NAT according to the scheme, as they drew in the 2005 Cisco manuals.
Since the server is old, Mimikatz is guaranteed to work right from memory:
I get the local administrator password, tunnel RDP traffic over TCP, and go to a cozy desktop. Since I could do anything with the server, I remove 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 set up an OpenVPN server on 443, add NAT functionality to my VPN traffic, and get direct access to the DMZ network in unlimited form through my OpenVPN. It is noteworthy that ISA, having some non-disabled IPS functions, blocked my traffic with port scanning, for which it had to be replaced with a simpler and more compliant RRAS. So pentesters still sometimes have to administer everything.
An attentive reader will ask: “What about the second site - a wiki with NTLM authentication, about which so much has been written?” More on this later.
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 the security of services within the DMZ segment, especially since there are now many more of them open for research. A typical picture during a penetration test: the external perimeter is better protected than internal services, and when gaining any access to a large infrastructure, it is much easier to obtain extended rights in a domain only due to the fact that this domain begins to be available to the toolkit, and secondly, in an infrastructure with several thousand hosts, there will always be a couple of critical problems.
I charge scanners via DMZ through an OpenVPN tunnel, and wait. I open the report - again nothing serious, apparently someone walked in the same way before me. The next step is to investigate how hosts communicate within the DMZ network. To do this, for starters, the usual Wireshark is launched with listening for broadcast requests, primarily ARP. ARP packets were collected for a whole day. It turns out that multiple gateways are used in this segment. This will come in handy later. By piecing together ARP request-response data and port scan data, I found user traffic exit points from inside the local network in addition to those services that were previously known, such as the web and mail.
Since at the moment I did not have any access to other systems and there was not a single account for corporate services, it was decided to extract 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 for the “man in the middle” attack were selected, then by short-term launch for 5-10 minutes, with a timer to restart the server in case of a “freeze”, some network traffic was received. As in a joke, there were two pieces of news:
- Good: a lot of credentials were caught and the attack as a whole worked.
- The bad news: all the credentials were from the customer's own clients. When providing support services, the customer's specialists connected to the services of customers who did not always have traffic encryption configured.
As a result, I got hold of a lot of credentials that are 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 data, direct access to RDP from Windows XP in the local network and other obscurantism. It turned out a sort of .
I also found a funny opportunity to collect letters 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 Andrey asks his namesake to resend the documentation, and it is laid out on a cloud disk with a login, password and a link in one response letter:
This is another reminder to encrypt all services. It is not known who and when will read and apply your data specifically - the provider, the system administrator of another company, or such a pentester. I am silent about the fact that many people can simply intercept unencrypted traffic.
Despite the apparent success, it did not bring it closer to the goal. It was possible, of course, to sit for a long time and fish out valuable information, but it’s not a fact that it would appear 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 mind. There is such a utility, called Responder (it's easy to find examples of use by this name), which, by "poisoning" broadcast requests, provokes connections over a variety of protocols such as SMB, HTTP, LDAP, etc. in various ways, then asks each person who connects to authenticate and adjusts it so that authentication goes through NTLM and in a mode transparent to the victim. Most often, an attacker collects NetNTLMv2 handshakes in this way and quickly recovers domain passwords of users from them using a dictionary. Here I wanted something similar, but the users were sitting “behind the wall”, or rather, they were separated by a firewall, and accessed the WEB through the Blue Coat proxy cluster.
Remember, I specified that the Active Directory domain name matched the "external" domain, that is, it was company.ru? So, Windows, more precisely Internet Explorer (both 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 access to a "gray" IP address or a short DNS name, that is, without dots. Since there was a server with a “white” IP and a DNS name preobrazhensky.company.ru, and domain machines usually receive an Active Directory suffix of the domain via DHCP for simplified name entry, it was enough for them to write the URL in the address bar so that they find the right path to the compromised urologist server, not forgetting that this is now called "Intranet". That is, at the same time giving me the NTLM-handshake of the user without his knowledge. What remains is to get the client browsers to think about the urgent need to contact this server.
The wonderful utility Intercepter-NG came to the rescue (thanks ). It allowed you to change traffic on the go and worked great on Windows 2003. There was even a separate functionality for modifying only JavaScript files in the traffic stream. A sort of massive Cross-Site Scripting was planned.
Blue Coat proxies, through which users accessed the global WEB, periodically engaged in caching static content. By intercepting traffic, it was clear that they were working around the clock, endlessly requesting frequently used static to speed up the display of content during peak hours. In addition, BlueCoat had a specific User-Agent, which clearly distinguished it from a real user.
Javascript was prepared, which, using Intercepter-NG, was embedded for an hour at night on each response with JS files for Blue Coat. The script did the following:
- Identified the current browser by User-Agent. If it was Internet Explorer, Edge or Chrome, it worked further.
- Waiting for the DOM of the page to be generated.
- Inserted an invisible image into the DOM with the src attribute of the view :8080/NNNNNNN.png, where NNN are arbitrary numbers so that BlueCoat doesn't cache.
- Exposed a global variable-flag that the injection was made and there is no need to insert pictures anymore.
The browser tried to load this picture, on port 8080 of the compromised server, a TCP tunnel was waiting for it to my laptop, where the same Responder was launched, requiring the browser to log in via NTLM.
Judging by the Responder logs, in the morning people came to work, turned on their workstations, then massively and imperceptibly began to visit the urologist's server, not forgetting to “merge” NTLM handshakes. Handshakes were pouring all day and clearly accumulated material for a deliberately successful attack to recover passwords. The Responder logs looked something like this:
Mass secret visits to the server of the urologist by users
You probably already noticed that this whole story is built on the principle “everything was fine, but then a bummer was waiting, then there was an overcoming, and then everything came to success.” So, here was waiting for a bummer. Of the 2 unique handshakes, not a single one was revealed. And this is taking into account the fact that even on a laptop with a dead processor, these NTLMvXNUMX handshakes move at a speed of several hundred million attempts per second.
I had to arm myself with password mutation techniques, a video card, a thicker dictionary and wait. After a long time, several accounts with passwords like “Q11111111….1111111q” were revealed, which suggests that all users were once forced to come up with a very long password with a different case of characters, which was also supposed to be complex. But you can’t just fool a seasoned user, and in this way he made it easier for himself to remember. In total, about 5 accounts were opened, and only one of them had some valuable rights to the services.
Part 3. Roskomnadzor strikes back
So, the first domain accounts were received. If you have not fallen asleep from a long read by this point, you 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 entrance was made there first. Digging into the internal knowledge base quickly brought results:
- The company has a WiFi network with domain account authentication with access to the local network. With the current set of data, this is already a working attack vector, but you need to go to the office on your feet and be located somewhere on the territory of the customer's office.
- There was an instruction according to which there was a service that allowed ... to independently register a “second factor” authentication device if the user is inside the local network and confidently remembers his domain login and password. In this case, "inside" and "outside" was determined by the availability of the port of this service for the user. The port was not accessible from the Internet, but it was quite accessible through the DMZ.
Of course, the “second factor” was immediately added to the compromised account in the form of an application on my phone. There was a program that could either loudly send a push request to the phone with "approve" / "disapprove" buttons for the action, or silently show the OTP code on the screen for further self-typing. Moreover, the first method was assumed by the instruction to be the only correct one, but did not work, unlike the method with OTP.
With the broken “second factor”, we managed to log into Outlook Web Access mail and remote access to the Citrix Netscaler Gateway. There was a surprise in the mail in Outlook:
In this rare shot you can see how Roskomnadzor helps pentesters
These were the first months after the famous "fan" blocking of Telegram, when entire 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 her account began to be used during frankly non-working 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 way limiting actions through standard management shells. By occupation, my "victim" got only 1C:
After walking around the 1C interface for a bit, I found that there are external processing modules. 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 1C programmer friends to create a processing that would take a string and execute it. In the 1C language, the process launch looks something like this (taken from the Internet). Agree, the syntax of the 1C language amazes a Russian-speaking person with its immediacy?
The processing was perfectly executed, what pentesters call a “shell” turned out - 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 an attack vector over WiFi.
They say on the Internet that there was still a delicious free catering in the customer’s office, but I still preferred to develop an attack through a remote location, it’s calmer.
AppLocker was activated on the application server with Citrix, but it was bypassed. The same Meterpreter was loaded and launched via DNS, since the http (s) versions did not want to connect, and I did not know the internal proxy address then. By the way, from that moment on, the external pentest, in fact, finally switched to the internal one.
Part 4
The first thing a pentester has to do when gaining control of a domain user's session is to gather all the information about the rights in the domain. There is such a BloodHound utility that automatically allows you to upload information about users, computers, security groups via the LDAP protocol from a domain controller, and via SMB - information about which user logged in where recently and who is the local administrator where.
A typical technique for seizing domain administrator rights looks like a cycle of monotonous actions:
- We go to domain computers where there are local administrator rights, based on already captured domain accounts.
- We run Mimikatz and get cached passwords, Kerberos tickets and NTLM hashes of domain accounts that have recently logged into this system. Or we take a memory image of the lsass.exe process and do the same on our side. This works well with Windows younger than 2012R2/Windows 8.1 with default settings.
- We determine where the compromised accounts have local administrator rights. We repeat the first point. At some stage, we get administrator rights for the entire domain.
“End of the Cycle;”, as 1C programmers would write here.
So, our user turned out to be a local administrator on just one host with Windows 7, in the name of which there was the word "VDI", or "Virtual Desktop Infrastructure", personal virtual machines. Probably, the designer of the VDI service meant that since VDI is the user's personal operating system, then let the user change the software environment as he likes, anyway, the host can be “reloaded”. I also thought that the idea was generally good, went to this personal VDI host and made a nest for myself there:
- I installed an OpenVPN client there, which made a tunnel through the Internet to my server. The client had to be forced to go through the same Blue Coat with domain authentication, but OpenVPN managed, as they say, “out of the box”.
- Installed on VDI OpenSSH. Really, what is Windows 7 without SSH?
This is what it looked like live. I remind you that all this has to be done through Citrix and 1C:
One technique for promoting access to neighboring computers is checking local administrator passwords for a match. Luck immediately awaited here: the NTLM hash of the default local administrator (who was suddenly called Administrator) approached through a pass-the-hash attack to neighboring VDI hosts, of which there were several hundred. Of course, the attack immediately went through them.
This is where VDI administrators shot themselves in the foot twice:
- The first time they didn't put VDI machines under LAPS, essentially keeping the same local administrator password from an image that was mass-deployed to VDI.
- The default administrator is the only local account that is vulnerable to pass-the-hash attacks. Even with the same password, mass compromise could be avoided by making a second local administrator account with a complex random password, and blocking the default one.
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 searched for them in the BloodHound graphs for the path to the domain administrator. With hundreds of hosts available, I found this way fairly quickly. Domain administrator rights have been obtained.
Here is a picture from the Internet showing a similar search. Links show who is admin where and who logged in where.
By the way, remember the condition from the start of the project - "do not use social engineering." So, I propose to think about how cut off all this Bollywood with special effects would be, if it were still possible to use banal phishing. But personally, it was very interesting for me to do all this. I hope you enjoyed reading this. Of course, not every project looks like this intriguing, but the work as a whole is very puzzling and does not allow to stagnate.
Probably, someone will have a question: how to protect yourself? Even this article describes many techniques, many of which Windows administrators don't even know about. However, I propose to look at them from the perspective of the hackneyed principles and measures of information security:
- don't use legacy software (remember Windows 2003 in the beginning?)
- do not keep unnecessary systems turned on (why was the urologist's website?)
- check user passwords for strength on their own (otherwise soldiers will do it ... pentesters)
- do not have the same passwords for different accounts (VDI compromise)
- and other
Of course, this is very difficult to implement, but in the next article we will show in practice that this is quite possible.
Source: habr.com