On August 10, 2022, Cisco Talos Intelligence disclosed a successful cyber-attack which appears to be a targeted attack that resulted in ‘multiple system’ compromises. This post will rely on data, information, and IOCs shared by Talos Intelligence on their blog post and analyze them further. This blog post will not cover technical details. But we will this incident as an opportunity to understand the attack itself and tactics, techniques, and procedures known as TTPs and see how Cyber Kill Chain can help us stop bad actors.
I won’t go into detail and tell you what Cyber Kill Chain is, but in case you want to learn about it, you can just click here and read it from there. One thing I want to point out is I am not interested in telling things like telling you a secret or talking about mysterious stuff like some ‘cyber pros’ out there do. Our goal is to keep things simple as they are and take this as an opportunity to learn something.
When I first started reading about Cyber Kill Chain, I thought it was just telling us how the attack life cycle works. But that assumption is not true. It’s, as defenders, actually telling us how to protect clients against bad guys. When I say defenders, I mean vendors who create security tools, rule makers, and analysts.
Here is how:
From the experience, we know that the malware types, attack vectors, tools, and attackers can change from time to time but TTPs and attack chain remains the same or similar. So, if we can create or obtain effective and efficient security tools, create sufficient rules, and have data analyzing capability, we will be more successful at stopping attackers. There are three actors here to achieve this goal: vendors, rule makers, and analysts. Vendors are the first link in this chain. Because engineers can create effective rules as much as the tools allow them to do so and analysts can be more successful at stopping attacks if the tools provide accurate and critical logs to them. There are a few security software features that can help to achieve this: customization, real-time threat detection capability, and critical log collection. Customization allows the rule makers to create custom security rules per their environment and new attack patterns. It also allows security analysts to create custom searches, search more logs as needed, and correlate data to make better decisions. This reminds me of something I’ve heard and never forgotten from a CISO during an engagement. Upon a question he said, tools can’t stop attackers but analysts can. That’s true, if we arm analysts whose job is monitoring security tools and reacting to events, with effective and efficient instruments, they will be more successful at stopping attacks and attackers. That means effective threat monitoring is relying on tools and security engineers. I will not present an example here because our example is already on hand.
So, now we already talked about how things work from the defender’s perspective, now let’s work on our example which is the Cisco attack. We will cover the kill chain framework according to the information provided for this attack and we might just skip a step in the chain if no related information is provided.
Reconnaissance: At this stage, threat actors select their target, start observation of data from open sources or leaked data, and obtain hack tools. Let’s see what Talos Intelligence says: “During the investigation, it was determined that a Cisco employee’s credentials were compromised after an attacker gained control of a personal Google account where credentials saved in the victim’s browser were being synchronized.” From this, we know that this attack was started by compromising a user’s Google account. Okay, that means that attackers worked on obtaining the employee’s Gmail address from open sources and started a phishing attack on the employee/s or obtained it from leaked/stolen credentials or maybe another method. If you read through the article you’ll see that they knew well who they are attacking or who to attack.
Let’s accept that there are a few steps to take to avoid or minimize this threat at this stage but also we can’t stop people from collecting our data from open source individually and attacking us or companies. Also, remember that amount of information they will collect about you from open sources will be the same as you or 3rd parties shared on the Internet. Let’s how we could stop this. From the user perspective turning on security features on your account, using strong credentials, and using MFA are very important. For example, if these features were turned on, Google would be able to send a pop-up notification to the user when someone from another location accessed their account. How about the company? Well, there are a lot here: They should have either restricted using a personal account on their device, provided a third-party password manager service, or restricted the user from saving their passwords to the browser in this case Chrome by managing it. These may sound like very specific or detailed things but also we know that attackers always find a weak link to use or a vulnerability to exploit. How Kill Chain would help? We need an alert for this. The only alert would be a phishing submission from the user, for the defenders to analyze and investigate this attack.
Intrusion — Initial Access: It seems once attackers got access to the user’s Google account, they dumped credentials from the Chrome browser including work account credentials since it was syncing. So we know that either the employee was using their Gmail account on their work device or they were using a personal device for work. Here is what happens then: “After obtaining the user’s credentials, the attacker attempted to bypass multifactor authentication (MFA) using a variety of techniques, including voice phishing (aka “vishing”) and MFA fatigue, the process of sending a high volume of push requests to the target’s mobile device until the user accepts, either accidentally or simply to attempt to silence the repeated push notifications they are receiving.” I can say that this post by Talos is one of the most transparent incident disclosure that I’ve ever read but it’s also missing stuff that might be intentionally preserved. But it still gives us lot’s of clues about what’s happened. When credentials were dumped they should have received an alert. Let’s say this was done on the attacker’s machine and no alerts were triggered as a matter of course. It seems that the user/users received a high number of MFA push notifications but these were not reported/alerted or investigated. They also mentioned a ‘vishing’ attack on some of their employees which is another red flag. Remember you have tools, rule makers, and analysts whose job is to monitor and investigate notable events. But at this stage either they were not able to trigger a rule and alert or there was no sufficient monitoring. The purpose of this post is not to criticize folks at Cisco but there is a basic rule here if we can’t spot it, we can’t stop it!
Exploitation: At this stage, we are expecting to see the attackers attempting to exploit vulnerabilities, and deliver malicious code onto the system/s. Let’s see what Cisco Talos says: “Once the attacker had obtained initial access, they enrolled a series of new devices for MFA and authenticated successfully to the Cisco VPN. … The actor in question dropped a variety of tools, including remote access tools like LogMeIn and TeamViewer, offensive security tools such as Cobalt Strike, PowerSploit, Mimikatz, and Impacket, and added their own backdoor accounts and persistence mechanisms.” So to spot the bad guys at this stage first, we should have rules in place when a device -what, even a series of devices?- is being registered to an environment and new user/s are being created that will trigger an alert. These types of alerts should be analyzed carefully and verified with system admins at least. For each stage, attackers have tools to use. In this case, we see that they dropped a few of them, Cobalt Strike, PowerSploit, Mimikatz, and Impacket, on the system which any security tool would trigger an alert for it.
Privilege Escalation: Now since they are on the system and they usually check user privileges and if the compromised account is not an admin account, they should work on escalating privileges. This also needs some operating system-specific tool usage. Talos: “The attacker then escalated to administrative privileges, allowing them to log into multiple systems, which alerted our Cisco Security Incident Response Team (CSIRT), who subsequently responded to the incident. … Once on a system, the threat actor began to enumerate the environment, using common built-in Windows utilities to identify the user and group membership configuration of the system, and hostname, and identify the context of the user account under which they were operating. We periodically observed the attacker issuing commands containing typographical errors, indicating manual operator interaction was occurring within the environment.” Now we know CSIRT was alerted and able to spot the bad guys. But what, they seem to be rushing… (maybe running fast to deploy ransomware?). Well, from the security perspective, there are some commands/utilities such as net, whoami, hostname, ipconfig -with specific arguments and in a context- when they are used/run, then there must be an alert for it. And that’s what we see here.
Here is an example of how they added an account named “z” to the local administrators group which alerted CSIRT.
Lateral Movement: Per events happening, we are expecting the CSIRT to stop them at the Privilege Escalation stage. We know that they also gained access to multiple systems but let’s see what happens. “After establishing access to the VPN, the attacker then began to use the compromised user account to logon to a large number of systems before beginning to pivot further into the environment. They moved into the Citrix environment, compromising a series of Citrix servers and eventually obtained privileged access to domain controllers. After obtaining access to the domain controllers, the attacker began attempting to dump NTDS from them using “ntdsutil.exe” …” A series of suspicious activities, if we have not spotted them yet, right? Honestly, I thought they are Quantum Ransomware group until I read to the end. Because I know those guys are technically moving quickly to deploy ransomware. So now the bad guys are inside the network, lots of suspicious events happening, and we should have more rules to trigger and follow their footprints. As we can see, CSIRT was able to follow the attacker’s footprint and identify compromised systems. I’m still unclear how they were able to move laterally and compromise multiple other systems since they were spotted while on a single system. Because we assume that those devices were identified and isolated from the network but also that might not be always the case. I’m saying that because we are dealing with computer systems. If the endpoint protection tool does not isolate a device immediately, then no way to stop things. One thing that comes to mind is that the attackers registered a few devices, but they did not use them at once. CSIRT was able to identify malicious activities from a device and maybe, blocked that device by its MAC address or another way but they did not know about other devices (unmonitored devices) and the attackers used new devices as they move. Let’s say we do not know about attackers yet, and how we would identify malicious or suspicious traffic here. If you look at the attacker’s activities, you will notice that it has a pattern: A couple of new devices/accounts are registered and they are given access to multiple systems. The event itself, type of devices, and account names should give us a clue. For instance, each company has a naming pattern for accounts such as numbers, numbers, letters, or names, if the account name does not follow that pattern, then it is a red flag. Wherever you a deviation from normal, you should report that action. Of course, we are assuming that we got alerted by security tools.
Obfuscation / Anti-forensics: If this attack did not continue in months -we’ll discuss dwell time later- the attackers were definitely aware of being spotted because they are acting very fast to achieve their goal or they were just rushing for deploying ransomware but also were well-prepared for this scenario. Per our attack kill chain, now we expect to see the bad guys attempt to cover their tracks, clear logs such as using wevutil, and try evading any detections. “The attacker also took steps to remove evidence of activities performed on compromised systems by deleting the previously created local Administrator account. They also used the “wevtutil.exe” utility to identify and clear event logs generated on the system. In many cases, we observed the attacker removing the previously created local administrator account.” As we all know attackers tend to use OS native utilities as these tools are already on the system and known benign binaries. But of course, there are patterns or arguments such as in the picture below when matched or passed that should generate alerts. These are usually achieved via custom rules. For example, if a program is designed to self-delete itself, that’s a huge sign of malware, or if someone is clearing logs that might be a sign of malicious activity if not a system admin or software designed to clear some type of data to free disk space. And the analyst is the one to make that distinction. What logs they are clearing? Are they clearing security logs or something else?
Exfiltration: In many cases, we see that attackers first move data to a compromised internal server and then exfiltrate it from the internal host to an external command and control server. And the final stage is to encrypt files on the system, leave a ransom note, and demand ransom. This is called a double-extortion attack. “Throughout the attack, we observed attempts to exfiltrate information from the environment. We confirmed that the only successful data exfiltration that occurred during the attack included the contents of a Box folder that was associated with a compromised employee’s account and employee authentication data from the active directory. The Box data obtained by the adversary in this case was not sensitive.” So, they were able to exfiltrate some type of data but obviously, they were not successful at it, therefore, they were unable to reach the final stage. If we were unable to spot them until this step, we could see a large amount of data being exfiltrated, and honestly, it would not be a good sign at all. As we can see from Cisco’s example there are multiple stages of an attack, and the Cyber Kill Chain framework guides us and provides the opportunity to spot and stop adversaries. A good security tool can correlate events, trigger rules, and generate alerts with sufficient logs. A trained eye, an analyst, can also easily spot suspicious patterns and warn system owners/admins and report suspicious activities.
Threat Actors Love Using LOLBins:
Let’s say, a rule was triggered, an alert was generated, and here are the event logs: “net user z Lh199211* /add” — The analyst should know account name patterns for legit accounts in their environment and spot this as unusual.
Another one is enabling RDP access: “netsh advfirewall firewall set rule group=remote desktop new enable=Yes”, This is also a critical configuration change that allows remote access to a device which is always considered a red flag.
One more example, “reg save hklm\sam sam” as we can see, the bad guys are attempting to dump the Security Account Manager registry which contains the password hash values for all local accounts on the machine. Suspicious enough, ha!
A Little About Attack Time-Cycle and Notable Events:
On May 24, 2022, Cisco became aware of a potential compromise
On June 3rd, June 13th, and Saturday, July 30th threat actor sends multiple emails to Cisco demanding ransom.
This incident was made public on Wednesday, August 10, 2022.
During this period, I think Cisco worked on the incident and wanted to make sure that no sensitive data was exfiltrated as expected.
Below is the list of malicious domains (C2) that were used during this attack.
I double-checked the Talos post but I did not see any comment on the attack type. If you look at the domain names above, you will see that 13 out of 14 domains contain the word cisco in their name. Well, with all other attack vectors enumerated in this blog, this falls under ‘targeted attack’, and domain spoofing is used as a method for this. Why? Because when someone sees “cisco” in the domain name and doesn’t pay attention to details, they might just think it’s a legit cisco host. Sneaky!
Another interesting thing about these domains is the domain creation time. One domain was created on May 20th, 2022, which is the earliest one I found on OSINT. And the other ones appear to be registered after May 24th and on different days. They used different domain registrars such as Cloudflare, Dynabot, Namecheap, Godaddy, and Hostinger. I could not find whois information for domains that were registered through Cloudflare even on their site which is interesting. From this information, my guess is that threat actors used kazaboldu[.]net (the only domain without cisco word!) which is created on May 20th, (Registrar: realtimeregister[.]com, Country: Russia) for a spear-phishing attack and gained access to the employee’s Google account. And CSIRT spotted them on May 24th. The dwell time seems to be 4 days. The threat actor took so many suspicious actions in a short period because they had a goal to deploy ransomware as quickly as they can. This resulted in being caught. It’s easier for defenders to spot these types of attacks because a series of suspicious activities happening in a short period can be easily correlated. Most security tools can detect this as part of behavior analysis. But this type of attack can also be hard for defenders to stop quickly. Because identifying compromised systems, blocking TA’s access, and completely stopping them takes time, and this may not always be possible in a short amount of time. Honestly, I’m not an expert on threat groups to identify them from TTPs but I can say that the domain registrar information here, and the threat actors’ action pattern support the Talos team’s idea which concluded as these guys are linked to a ransom gang and/or the Russian threat actors.
As I said before if we can’t spot it, we can’t stop it!
This is the end of our analysis of the Cisco Attack and Cyber Kill Chain. It’s also my first blog post both on cyber-security and Medium as a platform. I tried making it as simple as I can. If you liked my analysis please write it in the comments below. If you find anything that might not be correct or needs to be edited, you can say that in the comments too. And I will check and update the post as needed.
Thank you and I hope you enjoyed reading!
August 31, 2022.
Zerotrust13
