An advisory from the Australian Cyber Security Centre (ACSC) warns that highly sophisticated attacks are currently underway against organizations in Australia. Threat actors have successfully breached a number of networks and are using “living off the land” techniques to spy and exfiltrate data, while attempting to stay under the radar.

“Living off the land” is a strategy typical of advanced persistent threat (APT) groups; the strategy consists of using standard system utilities and legitimate third-party tools to conduct a cyberattack. This helps to evade easy detection. The threat actors also compromised legitimate Australian websites in order to use them as command and control (C&C) servers, thus better hiding their malicious communication.

Organizations are well advised to review the indicators of compromise (IOCs) released by the ACSC.

However, in order to gain comprehensive and immediate visibility into possibly compromised endpoints, no tool serves better than an endpoint detection and response (EDR) solution. As Forrester’s February 2020 Now Tech: Enterprise Detection and Response, Q1 2020 report states, “A key benefit of EDR products is the ability to hunt for indications that an adversary has eluded your security controls and is lying in the weeds of your infrastructure.”

ESET Enterprise Inspector (EEI) is ESET’s EDR solution and is specifically designed to detect the tactics, techniques and procedures used in targeted attacks by APT groups. Deploying EEI in your environment offers two key benefits:

1. Immediate visibility into events happening on endpoints

Nothing makes an incident responder’s job easier than a tool that can easily integrate with other tools, provide rich context to events and filtering data down to the specific behaviors that give away the presence of a threat actor. EEI provides context about the reputation and popularity of executables, as well as information on process trees, scripts, command line arguments, paths, signers and hashes.

In addition, EEI provides full transparency into its rule logic, allowing responders to understand why specific behaviors were detected. Visibility is further enhanced by extensive searching and filtering capabilities that help to pinpoint and quickly expose the behavior of malicious actors.

2. Suspicious activities automatically set off alarms

Backed by over 30 years of research into malicious behavior, ESET’s own malware research team has written over 300 custom rules that automatically detect specific behaviors commonly exhibited by APTs. EEI’s engine evaluates endpoint events against the rules. Offending processes, along with their process trees, are saved for further investigation by incident responders. EEI is powerful enough, for example, to automatically sound the alarm on numerous techniques identified by the ACSC in their advisory:

Every minute in an incident investigation is precious. Incident responders need powerful tools like EEI to complement their toolkit and empower them to easily and quickly reconstruct the adverse events happening on endpoints. The faster threat actors are discovered, the sooner remediation steps can be taken to get back to normal business operations.

However, if your security analyst discovers a more insidious pattern and intent at play behind all those single adverse events or, alternatively, an inexplicable system failure occurs, then you probably have a security incident serious enough to warrant calling in your computer security incident response team (CSIRT). With a well-thought-out incident response plan in hand, a well-trained CSIRT can confidently buckle down and take on any adversary attacking your network.

Four Phases of Incident Response

An important standard to check your incident response plan against comes from a NIST publication called the Computer Security Incident Handling Guide (SP 800-61). The guide details four phases of incident response: Preparation; Detection & Analysis; Containment, Eradication & Recovery; and Post-Incident Activity.

Figure 1: Incident Response Life Cycle (credit: NIST)

1. Preparation

Before any incident happens, it is important to establish the proper security controls that will minimize the incidents that can happen in the first place. In other words, your corporate network needs to be built and maintained with security foremost in mind.

That includes keeping servers, operating systems and applications up to date, suitably configured and fortified with malware protection. Your network perimeter should also be properly secured via firewalls and VPNs. Don’t forget about your Achilles heel – the seemingly innocent employees at their desks. A little training can go a long way to limit the number of incidents caused by bad employee behavior.

A crucial part of setting up your network is to make sure all the necessary monitoring and logging tools are in place to collect and analyze the events happening in your network. Options range from remote monitoring and management (RMM) tools to security information and event management (SIEM) tools, security orchestration automation and response (SOAR) tools, intrusion detection systems (IDS) and intrusion prevention systems (IPS), as well as endpoint detection and response (EDR) solutions.

More threat-averse organizations, such as banks and government bodies, take advantage of threat intelligence feeds like ESET Threat Intelligence Service to provide indicators of compromise that, if found within an environment, could start off the incident response process.

Deciding which monitoring and logging tools that are appropriate for your network will have a huge impact on your CSIRT’s detection and analysis activities, as well as the remediation options available to them.

Creating an incident response team

Next, establish an incident response team and keep it trained. Smaller organizations will most likely require only a temporary team made up of existing IT admins. Larger organizations will have a permanent CSIRT that will usually bring in other IT admins from the company only to aid in specific attacks; for example, a database admin to help analyze a SQL injection attack.

Outsourcing incident response to a managed security service provider (MSSP) is also an option, although it can be costly. If you are considering this option, you should be prepared for the longer response time. Some incident response team members may need to fly to your location, which is that much more time for threats to further impact your network.

Most importantly, any CSIRT needs to have staff members on board who understand how their network is built. Ideally, they should have experience in what “normal” looks like for you and what is unusual.

Management also needs to take an active role by providing the necessary resources, funds and leadership for a CSIRT to do its work effectively. That means providing the tools, devices and jump kits that will be needed by your CSIRT, as well as making the tough business decisions brought on by the incident.

Imagine, for example, that the CSIRT discovers that the business ecommerce server is compromised and needs to be taken offline. Management needs to quickly weigh the business impact of turning off or isolating the server and communicate the final call to the CSIRT.

Other staff members and teams throughout the organization also provide crucial support for a CSIRT. IT support staff can assist by shutting down and replacing servers, restoring from backups and cleaning up as requested by the CSIRT. Legal counsel and public relations teams are also important to manage any communication surrounding the incident with external media, partners, customers and/or law enforcement.

2. Detection & Analysis

In this phase, incident response analysts bring the power of their knowledge, experience and logical thinking to bear on the multifarious forms of data presented to them by all the monitoring tools and logs to understand exactly what is happening in the network and what can be done.

The task for the analyst is to correlate events so as to recreate sequences of events leading to the incident. Especially crucial is being able to identify the root cause in order to switch to phase 3’s containment steps as quickly as possible.

However, as pictured in NIST’s incident response life-cycle diagram, phases 2 and 3 are circular, meaning that incident responders may switch back to phase 2 to conduct further root cause analysis. In this cycle, it can happen that finding and analyzing some data in phase 2 suggests the need to take a particular mitigation step in phase 3. Taking that step can then uncover additional data warranting further analysis that leads to further mitigation steps, and so on.

Endpoint detection and response solutions, such as ESET Enterprise Inspector, that automatically flag suspicious events and save entire process trees for further examination by incident responders greatly bolster phase 2 activities.

3. Containment, Eradication & Recovery

In the third stage, the CSIRT decides on a method to stop the further spread of detected threats. Should a server be shut down, an endpoint be isolated, or certain services be stopped? The chosen containment strategy should consider the potential for further damage, preserving evidence and the time duration of containment. Usually, this means isolating compromised systems, segmenting parts of the network, or putting affected machines in a sandbox.

Sandboxing has the benefit of allowing for further monitoring of the threat as well as collecting more evidence. However, there is a danger that a compromised host can become further damaged while in the sandbox.

Legal counsel may determine that the CSIRT should collect and document as much evidence as possible. In this case, the transfer of evidence from person to person needs to be meticulously logged.

Once contained, any discovered malware needs to be deleted from compromised systems. User accounts may need to be disabled, closed or reset. Vulnerabilities should be patched, systems and files should be restored from clean backups, passwords should be changed, firewall rules should be tightened, etc.

A full return to normal business operations can take months depending on the incident. In the short term, increased or more finely tuned logging and monitoring should be established so that IT admins can prevent the same incident from happening again. The longer term might see more overarching infrastructure changes to help transform the network into a more secure one.

4. Post-Incident Activity

A CSIRT should document and provide an event reconstruction and timeline. This helps to understand the root cause of the incident and what can be done to prevent a repeat or similar incident.

This is also the time for all teams to review the effectiveness of the processes and procedures used, identify gaps in communication and collaboration difficulties, and look for opportunities to introduce efficiencies to the current incident response plan.

Finally, management needs to decide on the retention policy for evidence collected during the incident. So, don’t just the wipe the hard drives without first consulting your legal department. Most organizations archive incident records for two years to stay in compliance with regulations.

The more advanced the threat actors, the better they know how to sneak into and move undetected in your network. Clever adversaries count on the fact that a network administrator using only basic administration tools might not become suspicious from a first glance at network traffic. As Gartner noted in their December 2019 Market Guide for Endpoint Detection and Response Solutions (Gartner subscription required):

“Since the complexity of attacks and threats have both continued to develop at a pace that exceeds the ability of the tools and defenders to protect against them, security solution providers have developed more flexible tools with an “assume breach” mindset. EDR tools focus on the post-infection stage of the kill chain, providing the ability to detect and respond to advanced threats in a timely and effective manner.” 

In other words, we believe that getting beyond basic tools and adopting an endpoint detection and response (EDR) tool will significantly enhance a business’s level of visibility into advanced threats possibly already present in the network that might have otherwise gone undetected. The behavior of advanced threats is not always easy to distinguish from what is normal.

For example, consider what typical traffic in a network could look like: GIF, JPG or PNG image downloads and uploads; connections to popular social media sites like Twitter, Imgur or Reddit; or HTTP GET requests to legitimate domains. Perhaps there is even traffic from an HTTP proxy handling endpoints outside your LAN.

Everything in the network may seem to be running along smoothly and quietly, but it is paramount for security operations center (SOC) teams to see when all that is just a facade. Using an EDR tool like ESET Enterprise Inspector (EEI), SOCs are able to quickly unearth a lot of detailed information, helping to identify and investigate suspicious activity.

EEI works by matching event data from endpoints against a set of rules designed to flag malware-like or suspicious behavior, as well as low reputation and/or malicious executables. Matched events fire-off alarms and complete process trees are available for manual inspection in EEI:

Figure 1: Alarm details view in EEI with process tree

Getting deeper into the network with PolyglotDuke

As an example of the level of visibility that EEI provides, we can consider how the tool interacts with the presence of malware like PolyglotDuke, a downloader used by the Dukes threat group (APT29) in Operation Ghost.

PolyglotDuke comes as an encrypted DLL appended to a GIF89 image header. A separate .exe process – PolyglotDuke’s dropper – decrypts the DLL appended to the image header and drops it to a machine’s current working directory. The fact that a DLL with low popularity is loaded into a trusted process causes an alarm in EEI.

This PolyglotDuke DLL is then executed by a rundll32.exe process and starts contacting Twitter, Reddit, Imgur and other image-sharing sites to download Japanese, Chinese or Cherokee strings that encode the malware’s command and control server. Take a look at this Twitter post:

Figure 2: PolyglotDuke grabs its C&C URL – encoded in Cherokee – from a Twitter post

Normally, these actions would go unnoticed on a network level as it is usual business for employees to browse Twitter, download images, etc. Further, there is also nothing obviously suspicious about running DLL files with rundll32.exe – your operating system does it all the time. Since this process sets off other suspicious processes, however, a few alarms are raised in EEI.

Having decoded the addresses of its command and control servers, PolyglotDuke starts making HTTP GET requests to domains like rulourialuminiu.co[.]uk and powerpolymerindustry[.]com. The result of these requests is to download a JPG or PNG image file that has additional binary data appended to it. If you should visit these URLs, they redirect to similar looking, but legitimate counterparts: rulourialuminiu.ro and powerpolymer.net – a seemingly orchestrated ruse to hide its communications.

Finally, EEI sees PolyglotDuke extracting the appended binary data from the modified JPG or PNG images and performing some suspicious “write” activities. It may write a new executable to disk to be launched by CreateProcess. It may write a DLL to disk either for launch from another rundll32.exe process or for loading by LoadLibraryW. Last, but not least, it may write a JSON config file to the registry. These actions trigger the following alarms in EEI: “Trusted process loaded suspicious DLL” or “Rundll32 loaded DLL from suspicious location”:

Figure3: Alarms view in EEI with MITRE ATT&CK references

Looking at the alarms aggregated in EEI’s dashboard, administrators are able to correlate the data to the MITRE ATT&CK knowledge base via a direct reference to ATT&CK techniques. For example, Rundll32 (T1085) is documented in the ATT&CK Enterprise Matrix as a technique used by threat actors both for execution of malware components and defense evasion. In this way, network defenders gain a broader picture of the threat actors known to have utilized the identified techniques, as well as key prevention and remediation strategies.

Advanced reconnaissance and exfiltration with MiniDuke

The goal of PolyglotDuke is to download a backdoor called MiniDuke – a much more threatening prospect for affected organizations. EEI can reveal the processes that MiniDuke spawns, including the upload and download of files or the retrieval of system information like hostname or names of local drives. In total, MiniDuke packs 38 functions to enable cyberespionage.

One interesting trick that MiniDuke uses to blend into network traffic is to send POST requests to ecolesndmessines[.]org or salesappliances[.]com that appear as JPG file uploads. Upon inspecting these requests, however, administrators discover that the file merely has a JPG header masquerading the data as an image:

Figure 4: MiniDuke sends a POST request to its C&C server that looks like a JPG file upload

The malware writers obviously hope to hide their backdoor activities within the mass of images that are usually sent across a typical network.

One of the great benefits of EEI is that it allows administrators to download suspicious files for further analysis. So, looking at the MiniDuke version used in the mentioned Operation Ghost, the .exe file contains an invalid signature from the Microsoft Corporation. Some security products could be fooled, even by an invalid signature, into thinking that the file is benign.

Malware analysts on a SOC team can also download the files from EEI for reverse engineering in tools like IDA. There they can disassemble MiniDuke to find the pure x86 code, albeit hidden behind some deep obfuscation.

Having identified the offending processes and files, IT admins can use EEI to kill processes and, in the upcoming version 1.4 of EEI, to isolate compromised endpoints from the network in a one-click action. In addition, IT administrators are able to read the full set of over 300 rules packaged with EEI, create their own exclusions from rules and write their own custom detections. Providing even greater transparency and control over the alarm rule set greatly enhances the capabilities of SOC teams to defend their networks.

ESET will be presenting at the RSA Conference in San Francisco on February 24 - 27, 2020, where attendees can find a demonstration simulating the malicious mechanism of PolyglotDuke and MiniDuke – the favorite tools of the Dukes at play during Operation Ghost. Find us at Booth #753 in the South Hall.

Have macOS on the network? Version 1.4 of EEI has you covered. Learn more here.