Tracking LinkedIn and Facebook Requests to Bad Actors

Summary:

This document outlines the setup of a system for detecting specific types of events related to friend requests and invitations from suspected bad actors on platforms like LinkedIn and Facebook, as seen through Cisco IronPort syslog messages. Here's a summary of its key components: 1. **Use Case**: The purpose is to identify employees who receive friend requests or invitations from known bad actors by extracting names like "Eugenio Marrero" from various subject lines in email notifications such as invitations, endorsements, and congratulations. These extracted names are then compared against a list of known bad actors for detection. 2. **Example Subject Lines**: The document provides examples of typical subject lines that might appear when someone is sent a friend request or invitation on LinkedIn or Facebook: - "Eugenio Marrero's invitation to connect" - "See Eugenio Marrero's new endorsement" - "Congratulations on your work anniversary, Eugenio Marrero" - Mentions like "Congratulate Eugenio Marrero on the promotion" or "Your connection Eugenio Marrero has endorsed you!" 3. **Parser Overrides**: A parser is used to extract names from subject lines that may include common prefixes such as "RE" (reply) or "FWD" (forward), although these are not always reliably captured due to context variations in email messages. 4. **File Configuration**: To improve parsing, a directory named "ironport" is created within the FlexAgent environment with a properties file `ironp.sdkrfilereader.properties` that includes settings for regex patterns and other configurations to better parse subject lines: - Enables unparsed events. - Includes regex patterns specifically designed to capture names after certain keywords like "Congratulate". 5. **Default Submessage Configuration**: The configuration specifies how many patterns and fields should be considered for parsing, with each pattern having its own regex and field specifications. In summary, this document provides detailed instructions on enhancing the system's ability to detect suspicious events by configuring parsers specifically for social media platform interactions within email notifications, targeting known bad actors based on recognizable names from subject lines.

Details:

The provided information is a summary of a technical document related to detecting LinkedIn and Facebook requests from known bad actors, specifically in the context of Cisco IronPort event logs that are sent through syslog. Here's a breakdown of the key points: 1. **Use Case**: The customer wants to identify employees who receive friend requests or invitations on LinkedIn and Facebook from suspected bad actors. This involves extracting names like "Eugenio Marrero" from various subject lines, such as those related to invitations, endorsements, and congratulations, and then comparing these names against a list of known bad actors. 2. **Example**: The example provided includes several subject lines which are used to extract the name "Eugenio Marrero":

• Eugenio Marrero's invitation is waiting for your response

• See Eugenio Marrero's new endorsement

• Eugenio Marrero congratulated you on your work anniversary?

• Congratulate Eugenio Marrero on the new job

• Your connection Eugenio Marrero has endorsed you!

• Eugenio Marrero wants to be friends on Facebook

• Eugenio Marrero mentioned you on Facebook

3. **Parser Overrides**: For Cisco IronPort events sent through syslog, a parser is provided to capture specific patterns in email subject lines. The parser aims to catch emails that start with typical combinations of replies and forwards (like RE, FWD), but does not always succeed due to the nature of these phrases in different contexts. 4. **File Configuration**: To enhance parsing capabilities for such events, a directory named "ironport" is created within the FlexAgent environment, along with a properties file called `ironp.sdkrfilereader.properties`. This file contains configuration settings and regex patterns to improve parsing of email subject lines:

• Settings include enabling unparsed events (`do.unparsed.events=true`) and defining regex patterns for extracting names from the subject lines.

• The regex pattern is set up to capture names following certain keywords like "Congratulate", which can be used to identify specific bad actors based on name recognition.

5. **Default Submessage Configuration**: The configuration includes a default submessage descriptor that specifies how many patterns and fields should be considered for parsing, with each pattern having its own regex and field specifications. Overall, the document outlines a method for enhancing email event handling in a security context to detect suspicious activities by aligning with known bad actors based on specific name recognition from subject lines. The provided text outlines configuration settings for a system related to event pattern matching and parsing. Here's the breakdown of the instructions and configurations: 1. **Event Pattern Matching Configuration:**

• There are multiple patterns defined under `submessage<0>.pattern` with different regex (regular expressions) and fields. These patterns are used to extract information from messages based on specific keywords or phrases.

• The regex patterns capture details such as recent posts, endorsements, friend requests, job congratulations, and mentions.

• Each pattern is linked to a field named `event.sourceServiceName`, which presumably holds the name of the service or user involved in the event.

• Some patterns include additional conditions that need to be matched (e.g., specific keywords like "Re", "Fwd", etc.).

• For certain patterns, concatenation is applied using mappings (`mappings` property), where fields from different captures are combined.

2. **Directory and File Creation:**

• A new directory named `ironport_syslog` should be created under `/current/user/agent/fcp`.

• Within this directory, a properties file named `ironport.subagent.sdkrfilereader.properties` will be created.

• The properties file contains configuration settings for an extraprocessor:

• `extraprocessor.count=1`: Indicates there is one extraprocessor configured.

• `extraprocessor<0>.type=regex`: Specifies the type of extraprocessor as regex.

• `extraprocessor<0>.filename=ironport/ironp`: Defines the filename for the regex processor.

• `extraprocessor<0>.field=event.deviceCustomString6`: Maps the processed data to a field named `event.deviceCustomString6`.

• Additional properties like `flexagent`, `overrideeventmappings`, and `clearfieldafterparsing` are set, indicating that these settings should be applied specifically for this extraprocessor.

This configuration setup is geared towards enhancing event parsing capabilities in a system by defining specific rules to extract relevant information from various types of messages based on predefined patterns. The text provided appears to be a configuration or part of a larger system's setup related to processing conditions for user names within an event source. Here's a breakdown and summary of the key points mentioned: 1. **Condition Setting**:

• A condition is being set where `rocessor<0>.conditionfield` is assigned the value `event.sourceUserName`. This suggests that the system is focusing on processing or evaluating user names from an event source.

• The specific condition type is defined as `regex` (regular expression), which means the next part of the configuration (`conditionvalues`) will be interpreted using regex syntax.

• The values specified in `conditionvalues` are patterns that include common terms related to platforms like LinkedIn and Facebook, along with their domain suffixes (.COM or .com). This implies that the system is looking for user names containing these specific combinations.

2. **Active List and Rules**:

• There's a reference to an "Active List" and "Rules", which suggests that this configuration might be part of a larger rule-based system where certain conditions trigger actions or evaluations based on the settings defined in this segment.

3. **Screenshot Observation**:

• The screenshot mentioned seems to show a report displaying all hits, but only one specific hit related to LinkedIn is shown. This implies that the configuration has successfully identified and highlighted user names containing the specified patterns as linked to platforms like LinkedIn or FacebookMail.

In summary, this setup appears to be part of an automated system designed for pattern recognition in user names from a source event, focusing on identifying connections through specific social media platform handles (like LinkedIn) within email addresses ending in common domains (.COM or .com). The configuration uses regex to match patterns and highlights these matches in reports.

Disclaimer:

The content in this post is for informational and educational purposes only. It may reference technologies, configurations, or products that are outdated or no longer supported. If there are any comments or feedback, kindly leave a message and will be responded.