We’ve always been vocal about the imminent threat of breaches and propagated the message that irrespective of the size of your business, the industry you’re in, or your geography, you can be subject to a security breach. And unfortunately, history repeats itself often.

On May 11, 2020, Nippon Telegraph & Telephone (NTT), a large telecommunications company, revealed that attackers may have stolen data from its internal systems, affecting over 600 customers. 

The hack took place on May 7, 2020, and NTT detected the intrusion on May 11.

How it happened

Image source: https://www.ntt.com/about-us/press-releases/news/article/2020/0528.html


The company believes hackers started from an NTT base in Singapore, used this entry point to reach a cloud server located in Japan (Server B), moved to a server on NTT Communication’s internal network (Server A), and then accessed the Active Directory (AD) server.

The attack was on a hybrid environment (on-premises and cloud), which is similar to the configuration of most enterprises’ IT. NTT claims that several “multi-attack tools” as well as artificial intelligence and machine learning tactics were leveraged to conduct the attack.

Although the actual method of attack and tools used are still unclear, to understand the attack path better, we replicated how hackers could have traversed from server to server in NTT’s environment in our lab. The aim of this blog is to cover the possible ways the attack could’ve happened, helping you build an effective defense strategy.

Stage 1: Intrusion

The entry point for the breach was an NTT base in Singapore. An organization’s endpoints, especially its workstations, are often the prime point of entry in most attacks. They have lower security controls and usually do not store business-sensitive data but are still a part of the network, which makes them a sweet spot for intrusion.

The intrusion could have occurred many ways—it could have been a password-guessing attack from an external system, a remote access trojan injected via a removable drive, or a classic phishing attack using the coronavirus pandemic as a lure, where the downloaded attachment lodges malware in the victim’s system (e.g., the Windows registry).

In order to perform the intrusion, gathering the target domain information (like email addresses for a phishing attack) is crucial. Windows tools like PowerShell can help with information gathering and execution of attacks.

Stage 2: Escalation and lateral movement

After the initial infection, the attackers look to escalate privileges to acquire access to a system higher up the network hierarchy, thereby getting closer to their goal of reaching sensitive company data.

 This is the phase where attackers survey the domain to obtain target-rich information and plan their moves to escalate access to business servers that hold sensitive data. Below is an illustration that depicts the escalation pattern in the NTT breach.

Since we’re trying to replicate the attack pattern of the NTT breach, we’ll try to obtain access to the cloud server (Server B), then the internal server (Server A), and  eventually the AD server. Just like NTT’s environment, our lab has an on-premises AD server and a cloud server (Azure AD).

Access to the cloud server (Server B):

The first step is to obtain access to the cloud server. It’s important to note that the user workstation comprised during the intrusion phase may or may not have access to the cloud server.

 Utilizing free tools from the internet or searching social media can help find the users who work in the organization and their potential usernames, thereby their emails. The Python script in the screenshot below can help determine the validity of the email addresses.

Now that we have a list of potentially valid email addresses, let’s couple that with a classic password spray attack.

The probability that no user in the organization uses a trivial password is pretty low. Password attacks can be re-engineered and conducted on various types of cloud services, including Azure AD and Google G Suite.

Access to the internal production server (Server A):

With access to Server B, the next step is to somehow escalate privileges and obtain access to Server A, which is in close contact with the AD server. 

Most organizations that run cloud deployments alongside on-premises have two kinds of user identities on the cloud: synced and cloud-only identities. Either by using the GUI tools or running a few commands on a command-line shell, it is possible to determine the identities that are synced with the on-premises  environments, which means some of the users on the cloud may have access to Server A.

 Here’s what the output looks like with a cloud provider like Azure AD.

The attacker could use the obtained user details to conduct an automated password brute-force attack and get access to Server A, from where they can try to acquire access to the AD server.

Brute force attack on synced user identities

Extracting the keys to the kingdom (AD server):

Since Server A is a production server (meaning it’s privileged), there are many ways to gain access to the AD server from it:

  • There’s a good chance that the administrator account used to configure Server A was also used to configure the AD server. Or at the very least, the passwords of the administrator accounts on both servers may be the same. An attacker could simply try multiple password combinations against the admin account and replay the password on the AD server if found to be valid.

  • The attacker could also opt for a stealthier approach by extracting passwords from a memory dump (LSASS) of Server A.

  • The attacker could read into the registry to find saved information from remote sessions (RDP, FileZilla, SuperPuTTy) and extract the passwords of users who may have remotely accessed the AD server from Server A.

Extracting passwords from LSASS:

It is possible to generate a dump file of the LSASS using Task Manager or other Windows system tools. The dump file can then be copied and extracted from the attacker’s system to obtain user passwords.

Extracting passwords from remote tools:

Attackers can leverage publicly available PowerShell scripts to find and decrypt saved session information from remote access tools. The HKEY_USERS registry is queried for all users who have logged on to a domain-joined box at some point. For instance, if users from Server B remotely accessed Server A, then querying the registry key of Server B might give us the sensitive remote session saved information (like user account names and cleartext passwords).

Adding backdoor entries into the AD server:

If the user account compromised by the brute-force attack on Server A happens to be a privileged user, the privilege can be exploited to add backdoor entries into the AD server using a Windows installer application.

Once credentials are discovered or a backdoor entry is injected into AD, we’ve essentially received the keys to the kingdom—it’s game over. We can transfer the domain’s sensitive data to a remote server.

 Although NTT stopped its servers and blocked communication with the AD server as soon as the attack was discovered, it was too late. NTT later discovered by May 11 that another server, Server C, was compromised via Server B, and the company realized that the personal data of 621 customers had been leaked.

 The attack pattern above may not be an exact replica of what happened during the NTT breach, but it still sheds light on the fact that every organization, whether it’s running on-premises AD, cloud services, or even a fusion of both, is at significant risk.

 Unfortunately, the native auditing tools are very limited in their capabilities and do not have advanced enough monitoring capabilities to detect such sophisticated attacks. And the fact that attackers quickly traverse between multiple servers, workstations, and other endpoints makes auditing hybrid AD an extremely challenging task.

 With ManageEngine Log360, you can monitor your member servers, cloud services, workstations, and AD servers around the clock for activity that is malicious or sensitive. Its reports help you monitor:

  • Logon patterns (e.g., the servers accessed during the attack, the type of logon, and which users logged in and from where).

  • New process creations on servers.

  • Anomalous patterns, like logons at unusual times or a user accessing a server for the first time.

  • Advanced AD changes (e.g., malicious scripts used, file and folder modifications, and registry changes).

  • Changes on cloud services like Azure, AWS, and Google Cloud.

 Additionally, with the ability to configure customized alerts and instantly mitigate damage by shutting down devices, terminating user sessions, or carrying out more actions based on the scripts configured, you can be rest assured that every sensitive change is brought to notice and acted upon.

Download a trial version of Log360 now, and ensure you’re not the reason for history repeating itself again.