How to Implement persistent access on macOS through Emond

How to Implement persistent access on macOS through Emond

In this article, we will introduce how to implement persistent access on macOS through emond. According to Apple, the event monitoring process (emond) "accepts events from various services, runs through a simple rule engine, and takes corresponding actions ), these operations can be executed by executing commands, sending emails or short messages, and pushing notifications ". It sounds interesting. In fact, Emond has been available since OS X 10.7, so the details discussed in this article apply to the latest version of macOS (10.13.2 ).

Procedure

Emond is a common daemon. It is executed by launchd every time the system is started. The configuration file of launchd is the same as that of other system daemon processes: /System/Library/LaunchDaemons/com. apple. emond. plist. This configuration file determines when to execute emond and carries any expected options that are frequently used by LaunchDaemons. The emond. plist configuration file is located in the/etc/emond. d/directory. This file defines the rule path, UID/GID filtering, error log and Event Log Path, and some other options.

Figure 1: Content in emond. plist

Rule files are stored in the/etc/emond. d/rules/directory and must be in plist format. There is already a sample rule file (SampleRules. plist) in this directory. This example defines the name, type, and Action triggered by the event. There are several types of events (startup, periodic, auth. success, auth. failure, etc.). In this demonstration, we only use startup. Once loaded by emond, the startup event type triggers the rule. The periodic event type is triggered only after the "startTime" is defined. Similarly, auth. the success event type will only be triggered after successful user authentication; auth. failure is triggered on the verification failure event, and other event types are not listed one by one. Action defines what emond will do after an event occurs. Note that multiple actions can be defined in the rule. Only a few actions can be used for malicious purposes (such as running commands and sending emails). As you may have guessed, running commands can allow you to execute arbitrary system commands. For sending emails, the purpose is self-evident. For this demonstration, we will focus on executing commands.

Now we can demonstrate how to use the event monitoring process to establish persistent access. Emond is similar to any other LaunchDaemon. Launchd is responsible for executing all LaunchDaemons and LaunchAgent during the startup process. Because emond is started in this process, when executing a command, you should pay attention to what command you are executing and which command should be executed in which process. This is very important because the computer may not be connected to the Internet when an event is triggered and then an action (execute a command) is triggered, so any command that requires network access cannot be used. Next, we will show you how to create a rule file.

To create a rule file, we can use an existing SampleRule. plist file and modify it as needed.

Figure 2: samplerules. plist

This example contains the values required by our rule file. Specifically, we can delete the key "allowPartialCriterionMatch" and change the name as needed. The defined action must be modified based on the action type of the command. A complete example is as follows:

Figure 3: Example of persistent access

Note that the first operation is to sleep for 10 seconds to wait for the network connection. The value ranges from 10 seconds to 20 seconds, which may vary from person to person. The second one does not need to be introduced. Establish a session. However, this persistence mechanism has another strange thing: launchd will execute emond during startup, but the service will remain inactive until a file exists in the QueueDirectories path. This is specified in the LaunchDaemon configuration file/System/Library/LaunchDaemons/com. apple. emond. plist. Files placed in the QueueDirectories path do not need to follow the specific naming scheme, or they can be empty.

Figure 4: QueueDirectories in com. apple. emond. plist

After the plist file is put into the rules directory, the emond error log will show that the service has been started, and emond will not prompt that no rules can be found.

Figure 5: Error Log

Once the service starts, if you have defined a startup event type, the event will occur immediately and trigger any action. Now we can see that the Empire session is established.

Figure 6: Request

Figure 7: Session Creation

Emond is not a new OSX event monitoring mechanism, but it can be used as a new attack case. In retrospect, I did not mention this method in any of the macOS Threat reports I 've read at the time of writing this article. However, it may have been used in the wild, or its own animals and animals are harmless.

How to detect

This persistent access method requires some changes to the file system. Fortunately, macOS provides the fsevents API to capture file system events. In essence, fsevents records all events in each volume. Initially, the event is stored in the memory. Once the memory buffer is full or the volume is about to be detached, the event is written to the disk. The FSEvent log files are stored in gzip compressed format and follow the hexadecimal naming scheme. All log files are stored in a hidden directory:/fseventsd /. Root permission is required to access this directory. Note that the timestamp is not included in the log file. By accessing the API, we can use Python or Objective-C to filter all events received and generate alerts when a file creation/modification event occurs in the rules directory or QueueDirectory.

Click here to view the open-source fsevents Project

You can note that fswatch can provide a timestamp when an event is triggered. In addition, you can output it to any other command line for further processing. You can also specify multiple directories for monitoring. Once a plist file is placed in the rules directory, fswatch displays event details in a JSON string.

Figure 9: output when an event occurs

Of course, this is only the most basic example and may not be applicable to deployment in large MacOS environments. For the latter, osquery is more suitable. Osquery provides file integrity monitoring, which uses the fsevents api to record file system changes to files in a specific directory. For more information, click here. After installing osquery, you need to provide a configuration file to monitor file system events. Is a simple example to monitor all file system events in the rules directory. All events are queried at an interval of 60 seconds.

To be concise, we start the osquery daemon from the command line and use the-config_path flag to specify the configuration file. Once we create a plist file and place it in the rules directory, there should be an entry in the osquery Log File 60 seconds later. The results are recorded in/var/log/osquery/osqueryd. results. log by default. The output will include the path, host identifier, timestamp, file event type, and others.

The above detection methods cannot completely curb the malicious use of emond, but they are enough to serve as a good starting point.

Reference

Levin, J. (2017) OS Internals, Volume I: User Space. North Castle, NY: Technologeeks.com

Renault, J. (2016, 1_l). What is emond ?. Retrieved from: http://www.magnusviri.com/Mac/what-is-emond.html

Originally released on www.xorrior.com

Source: specterops

This article permanently updates link: https://www.bkjia.com/Linux/2018-02/150968.htm