Looking at our "first seen URLs" today, I noticed the following odd request:

/uddiexplorer/SearchPublicRegistries.jsp?operator=http://127.0.0.1:65535&rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search

UDDIs are a concept that had great promise but never quite made it. I would consider it dead at this point, but I wouldn't be surprised to find it in some enterprise systems. A "UDDI" (Universal Description, Discovery, and Integration) is a directory of web services. The idea behind is to automatically find web services belonging to an organization, including the associated documentation (WSDLs), to more or less automate the creation of clients for these web services. It was kind of a neat concept that never lived up to its promise.

This URL suddenly appears quite popular, with 1,446 scans today. In the past, we have seen occasional scans for similar "uddiexplorer" URLs. This time, the only IP scanning for them is 115.60.149.84. It appears to be a "random" Chinese ADSL IP address that only scans port 7001, a port typically assigned to WebLogic.

Back then, WebLogic suffered from an easily exploitable SSRF vulnerability, CVE-2014-4210. The almost ten-year-old vulnerability still appears to be attracting some attacks. Some attacks still appear to find this an attractive target. But the short lifetime of each scan likely shows that these scans are not successful.

We had small scans, with less than a dozen reports from our sensors, on March 1st and February. The "interesting part" is the "operator" parameter, which is the URL the attacker is trying to hit via SSRF. For example:

/uddiexplorer/SearchPublicRegistries.jsp?btnSubmit=Search&operator=http://cfveknb47rnbba000010ojuk6ku7xf$
zu.oast.site&rdoSearch=name&selfor=Business+location&txtSearchfor&txtSearchkey&txtSearchname=sdf

is an attempt to detect exploitability via OAST.

The graph below shows recent attempts containing the string "uddiexplorer":

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

Login here to join the discussion.

APT28 accesses poorly maintained Cisco routers and deploys malware on unpatched devices using CVE-2017-6742.

Overview and Context

The UK National Cyber Security Centre (NCSC), the US National Security Agency (NSA), US Cybersecurity and Infrastructure Security Agency (CISA) and US Federal Bureau of Investigation (FBI) are releasing this joint advisory to provide details of tactics, techniques and procedures (TTPs) associated with APT28’s exploitation of Cisco routers in 2021.

We assess that APT28 is almost certainly the Russian General Staff Main Intelligence Directorate (GRU) 85th special Service Centre (GTsSS) Military Intelligence Unit 26165. APT28 (also known as Fancy Bear, STRONTIUM, Pawn Storm, the Sednit Gang and Sofacy) is a highly skilled threat actor.

Download the UK PDF version of this report:

Download the US PDF version of this report:

Previous Activity

The NCSC has previously attributed the following activity to APT28:

• Cyber attacks against the German parliament in 2015, including data theft and disrupting email accounts of German Members of Parliament (MPs) and the Vice Chancellor
• Attempted attack against the Organization for the Prohibition of Chemical Weapons (OPCW) in April 2018, to disrupt independent analysis of chemicals weaponized by the GRU in the UK

For more information on APT28 activity, see the advisory Russian State-Sponsored and Criminal Cyber Threats to Critical Infrastructure and Russian GRU Conducting Global Brute Force Campaign to Compromise Enterprise and Cloud Environments.

As of 2021, APT28 has been observed using commercially available code repositories, and post-exploit frameworks such as Empire. This included the use of PowerShell Empire, in addition to Python versions of Empire.

Reconnaissance

Use of SNMP Protocol to Access Routers

In 2021, APT28 used infrastructure to masquerade Simple Network Management protocol (SNMP) access into Cisco routers worldwide. This included a small number based in Europe, US government institutions and approximately 250 Ukrainian victims.

SNMP is designed to allow network administrators to monitor and configure network devices remotely, but it can also be misused to obtain sensitive network information and, if vulnerable, exploit devices to penetrate a network.

A number of software tools can scan the entire network using SNMP, meaning that poor configuration such as using default or easy-to-guess community strings, can make a network susceptible to attacks.

Weak SNMP community strings, including the default "public," allowed APT28 to gain access to router information. APT28 sent additional SNMP commands to enumerate router interfaces. [T1078.001]

The compromized routers were configured to accept SNMP v2 requests. SNMP v2 doesn’t support encryption and so all data, including community strings, is sent unencrypted.

Exploitation of CVE-2017-6742

APT28 exploited the vulnerability CVE-2017-6742 (Cisco Bug ID: CSCve54313) [T1190]. This vulnerability was first announced by Cisco on 29 June 2017, and patched software was made available. 

Cisco's published advisory provided workarounds, such as limiting access to SNMP from trusted hosts only, or by disabling a number of SNMP Management Information bases (MIBs).

Malware Deployment

For some of the targeted devices, APT28 actors used an SNMP exploit to deploy malware, as detailed in the NCSC’s Jaguar Tooth Malware Analysis Report. This malware obtained further device information, which is exfiltrated over trivial file transfer protocol (TFTP), and enabled unauthenticated access via a backdoor.

The actor obtained this device information by executing a number of Command Line Interface (CLI) commands via the malware. It includes discovery of other devices on the network by querying the Address Resolution Protocol (ARP) table to obtain MAC addresses. [T1590]

Indicators of Compromise (IoCs)

Please refer to the accompanying Malware Analysis Report for indicators of compromise which may help to detect this activity.

MITRE ATT&CK®

This advisory has been compiled with respect to the MITRE ATT&CK® framework, a globally accessible knowledge base of adversary tactics and techniques based on real-world observations.

For detailed TTPs, see the Malware Analysis Report.

Tactic	ID	Technique	Procedure
Initial Access	T1190	Exploit Public-facing Application.	APT28 exploited default/well-known community strings in SNMP as outlined in CVE-2017-6742 (Cisco Bug ID: CSCve54313).
Initial Access	T1078.001	Valid Accounts: Default Accounts.	Actors accessed victim routers by using default community strings such as “public.”
Reconnaissance	T1590	Gather Victim Network Information	Access was gained to perform reconnaissance on victim devices. Further detail of how this was achieved in available in the MITRE ATT&CK section of the Jaguar Tooth MAR.

Conclusion

APT28 has been known to access vulnerable routers by using default and weak SNMP community strings, and by exploiting CVE-2017-6742 (Cisco Bug ID: CSCve54313) as published by Cisco.

TTPs in this advisory may still be used against vulnerable Cisco devices. Organizations are advised to follow the mitigation advice in this advisory to defend against this activity.

Reporting

UK organizations should report any suspected compromises to the NCSC.
US organisations should contact CISA’s 24/7 Operations Centre at This email address is being protected from spambots. You need JavaScript enabled to view it. or (888) 282-0870.

Mitigation

Mitigation

• Patch devices as advised by Cisco. The NCSC also has general guidance on managing updates and keeping software up to date.
• Do not use SNMP if you are not required to configure or manage devices remotely to prevent unauthorized users from accessing your router.
  • If you are required to manage routers remotely, establish allow and deny lists for SNMP messages to prevent unauthorized users from accessing your router.
• Do not allow unencrypted (i.e., plaintext) management protocols, such as SNMP v2 and Telnet. Where encrypted protocols aren’t possible, you should carry out any management activities from outside the organization through an encrypted virtual private network (VPN), where both ends are mutually authenticated.
• Enforce a strong password policy. Don’t reuse the same password for multiple devices. Each device should have a unique password. Where possible, avoid legacy password-based authentication and implement two-factor authentication based on public-private key.
• Disable legacy unencrypted protocols such as Telnet and SNMP v1 or v2c. Where possible, use modern encrypted protocols such as SSH and SNMP v3. Harden the encryption protocols based on current best security practice. The NCSC strongly advises owners and operators to retire and replace legacy devices that can’t be configured to use SNMP v3.
• Use logging tools to record commands executed on your network devices, such as TACACS+ and Syslog. Use these logs to immediately highlight suspicious events and keep a record of events to support an investigation if the device’s integrity is ever in question. See NCSC guidance on monitoring and logging.
• If you suspect your router has been compromised:
  • Follow Cisco’s advice for verifying the Cisco IOS image.
  • Revoke all keys associated with that router. When replacing the router configuration be sure to create new keys rather than pasting from the old configuration.
  • Replace both the ROMMON and Cisco IOS image with an image that has been sourced directly from the Cisco website, in case third party and internal repositories have been compromised.
• NSA’s Network Infrastructure guide provides some best practices for SNMP.
• See also the Cisco IOS hardening guide and Cisco’s Jaguar Tooth blog.

This product is provided subject to this Notification and this Privacy & Use policy.

Looking at changes that the internet as a whole goes through over time can be quite edifying. Since old servers are being decommissioned and new ones are being added all the time, the internet “landscape” can change significantly even over the course of a year or several months[1].

Because very few of us have ever had access to our own Carna botnet[2] or other solution, which would enable us to periodically scan the entire public IP space, we have to depend on information provided to us by specialized services (e.g., Censys or Shodan), which conduct such scans on our behalf, to learn of these changes.

Since we are dependent on these third-party services, which are, from our viewpoint, basically “black boxes”, any large spikes that may be seen in data gathered from them may be the result of a real, rapid change in the public IP space, or the result of misconfiguration or error in some internal mechanism used by these services. And, unfortunately, it is not always easy to say which is which… Which holds true even for a recent spike in the number of honeypots that Shodan detected.

As I mentioned in some of my previous Diaries[3], I use my TriOp tool to periodically gather significant amounts of data from Shodan about the global internet landscape, as well as about the situation in different countries. Among other information, I use the tool to gather the number of devices that Shodan classifies as “medical” systems, which are accessible from the internet, and a few weeks ago, a script that I use to identify significant changes in the data started to generate daily notices about a sharp relative increase in such systems in China (and, several days later, about a corresponding relative increase on a global level).

In view of the continuous nature of the change, I decided to take a closer look at what was happening.

After a little bit of digging, it turned out that basically all of the newly detected systems were also classified as “honeypots” and were in network ranges assigned to the China Education and Research Network Center (specifically, to the AS4538), as you may see in the following images showing the output from Shodan Trends service.

I have tried to manually scan relevant ports (e.g., TCP 11112/DICOM) on several of the newly detected systems using Nmap, however, none of them appeared to be opened. Nevertheless, even though I did the scan from several different locations around the world, this doesn’t necessarily make the Shodan results incorrect, since there may be some very strict geolocation-based filtering in place (e.g., access to these systems may only be allowed to Chinese IPs).

However, what makes it more probable that the sharp increase in the number of “medical honeypots” is a false positive, is the fact that this wasn’t the end of the interesting “spikes” related to AS4538.

After a little more digging, I noticed that besides an increase in the number of medical devices, Shodan also saw a very large increase in the number of systems it classified as honeypots in the same AS – specifically, an increase from approximately 600 public IPs, where honeypots were detected in February and March, to well over 7.5 million public IPs in April (at the time of writing, Shodan actually returns the count of honeypots detected in the AS at over 8.1 million).

This would seem to indicate that either the Chinese academic sector (based on the AS owner) just built the largest-ever research honeypot (the “Great honeypot of China”, if you will), or – which is probably more likely – that there was some error in the “black box” of Shodan in relation to classifying systems as honeypots.

Whatever the case is, the data we have available at this point is certainly intriguing, to say the least… I will try to monitor how the situation develops, and, if anything interesting turns out, we might get back to the topic in another Diary sometime in the future.

[1] https://untrustednetwork.net/en/series/open-port-statistics/
[2] https://census2012.sourceforge.net/paper.html
[3] https://isc.sans.edu/diary/TriOp+tool+for+gathering+not+just+securityrelated+data+from+Shodanio+tool+drop/27034

-----------
Jan Kopriva
@jk0pr
Nettles Consulting