Indicator of Compromise

What are Indicators of Compromise (IOCs)?

Indicators of Compromise are essentially the breadcrumbs that attackers leave behind and can include a wide range of data points, such as:

1. URLs or Domain Names: Indicative of connections to phishing sites or command-and-control servers.
2. IP Addresses: Notable for signaling communication with known malicious sources.
3. File Names: Signifying unauthorized alterations, potentially by an attacker.
4. File Hashes: Unique to specific pieces of malware or unauthorized software.

Vectra AI helps identifying and analyzing these IoCs, enabling SOC teams to swiftly respond to threats, mitigating potential damages and strengthening the security posture of the organization.

How to find IOCs (Indicators of compromise)

It’s important to keep an ear to the ground and make sure you are aware of any new compromises which are announced. But it’s just as important to be able to action new indicators of compromise when you hear of them. In this section, we will describe common IOCs, what they can indicate, why you should care, and how you can search for these IOCs in your network metadata.

Domain IOCs

Any external actor needs to be able to manage breaches from outside of the network, and domains are a key tool for this to be managed. As we saw recently in the SUNBURST SolarWinds exploit, Command & Control operations were performed through domains along the lines of appsync-api. eu-west-1[.]avsvmcloud[.]com. It is also a common tool in phishing attempts to use domain names which mimic popular sites in order to avoid suspicion in their target. For example, if a phishing attempt is made to steal credentials for someone’s outlook account, a domain such as outlook.com.enteryourpassword.tk might be used to avoid suspicion.

Domain Indicators of Compromise (IOCs) are a strong signal of compromise as these domains have been registered by a malicious actor and traffic for this express purpose. If any communication is seen to a domain IOC, then this strongly warrants investigation.

Known Bad Domains

You can easily convert a list of known bad domains from any source you have into a Recall query. We have created an excel file to do this for you, which you can from a Security Engineer, and given a list like this:

• Baddomain1[.]com
• Baddomain2[.]com

First convert this query to a Lucene query: Resp_domain:(baddomain1.com OR baddomain2.com)

Then run this query on your iSession Metadata Stream

Suspiciously Familiar Domains

1. Create a list of common domains which users on your network access. E.g.: facebook, gmail, outlook, your company intranet.  
2. Search for these items in your Vectra Recall iSession activity. E.g. Resp_domain( corpnet OR facebook OR gmail OR outlook OR office)
3. Save this search
4. Create a new “Data Table” Visualization with this Search as the source and split rows by “Term” and aggregate by “resp_domain” N.B. You could also split row by “Significant Terms”, which will show interesting and unusual terms, to reduce noise. Read more here: https://www.elastic.co/guide/en/elasticsearch/reference/current/searchaggregations-bucket-significantterms-aggregation.html  
5. A list of the most frequently accessed sites which match your search will appear. Legitimate domains should appear first. Hover over legitimate items and click to exclude these items.
6. Save this visualization

Any items left in this data table warrant further investigation, and if they are benign they should be excluded. At the start, you may have a lot of internal variations on your company’s domain name. For example, at Vectra AI we have a huge number of Vectra AI internal domains such as dev.vectrai.ai, HR assets in hr.vectra.ai etc. You will need to effectively triage out these false positives to get good, actionable data.

After a few days of manually checking this visualization, if you are happy with what results are remaining, you should turn this search into a Custom model by saving the underlying search, and then navigating to the “Manage” section of the Detect UI. In the “Custom Models” tab, find your new saved search and activate it within its edit modal.

IP addresses IOCs

You can easily convert a list of known bad IP addresses from any source you have into a Recall query. We have created an excel file to do this for you, which you can get off any Security Engineer, but given a list like this:

• 192.0.2.1  
• 192.0.2.2

First convert this query to a Lucene query: Id.orig_h:( 192.02.1 OR 192.02.2) OR Id.resp_h:( 192.02.1 OR 192.02.2)

Then run this query on your iSession Metatada Stream.

Ports IOCs

Novel Port Usage

Most software uses a standard set of external ports to communicate. When new ports are seen on the network, this can indicate the installation of new software in the environment; or, in some cases, communication from a compromised host. Vectra AI creates info level detections which report when novel external connections are observed in the environment.

You may want to aggregate these events using stream to leverage monitor if new software is being used on the network or potentially if malicious C2 channels are being set up. These events are mostly caused by benign user activity, but if your organization has a policy of limiting authorized applications, then spotting novel ports from systems outside of your IT admin team may be a sign of malicious activity, or a policy breach at the very least.

Spikes in Uncommon Port Usage

Spikes in network activity involving uncommon ports can be significant and warrant further investigation, as this port may be in use by malware to communicate with. A surge in activity necessitates further investigation.

The best way to review this activity like this is with a timeseries visualization. We have created one for you already in Vectra Recall called “Hunting off Indicators: Spikes in Uncommon Port Usage - data” ? Y axis to count.

An example of activity is below. The most common ports used have been excluded, and you can see two clearly spiking ports in use. Port 3283 is used for iChat, which is benign, and so could be excluded, but port 40063 is novel, and might warrant further investigation. You should also focus on standalone dots, which indicate spikes in traffic which were seen at no other time over your search period.

The steps involved above were:

• Create a date histogram with 24 hours of iSession data, with the count of connections as the y Axis
• Split the data into a separate series per responding port (id.resp_p)
• Filter out very common ports, e.g. 80/443 etc.
• Set a minimum threshold of activity to reduce the noise from minor ports by expanding “advanced” and setting {“min_doc_count”:X}, where X would depend on the size of activity on your network, we have set this as 5,000 connections by default.

You should look to duplicate this visualization and to update the search query with ports which you know to be safe within your organisation. (N.B. If you try to make changes to the default Recall visualization, your changes will be overwritten).

Similarly, a spike of data transfer from an uncommon port is also something that is worth looking into and ensuring you have validated it is safe.

This works in the same way as with the count of traffic, but you should set the y-axis to show the total data sent. We have created a visualization called “Hunting off Indicators: Spikes in Uncommon Port Usage – data” which you can use as a starting point for this.

See Also Link to Protocols over non-standard ports section

File Names IOCs

Malicious files can be transported on the network over SMB or other protocols, and then could get executed on target hosts either through remote processes or social engineering. Monitoring specific known bad file extensions which can be used malicious actors can find instances where files are being transferred for nefarious purposes.

The SMB File Metadata stream in Vectra Recall shows each filename interacted with, and these data can be mined to find data which may be suspicious.

There are 2 specific examples we will describe here, but your mileage may vary.

• Suspicious file names
• Suspicious paths

Suspicious File Names

File names which are written by users tend to have real English words in them, whereas from experience, file names can be weak indicators of compromise.

Examples of these are:

• Very long file names, e.g.. TotallyNotMalwareactuallyThisVeryMuchIsMalware.jpg
• Files without vowels, e.g. dwtdfh.doc

But searches like these can be very noisy without organizational context.

You can search for file names like these using regular expression (regex) searches. These searches can be quite slow, so we would recommend running a search over 15 minutes initially, and then expanding the time range once you reduce noise.

To search for file names of 50 characters of longer, you would run the following search. name:/.{50,}/

You could use similar logic for files without vowels, searching with: name:/.\[bcdfghjklmnpqrstvwxyz]{4,}../

This search is a regular expression, with the regular expression logic contained in the forward slashes /

• .* = match any path
• \\ = backslash to denote start of a filename
• [bcdfghjklmnpqrstvwxyz]{{4,} = 4 or more consonants in a row
• . = full stop (denoting the start of the extension
• .* = match any extension

You can also perform similar searches in metadata_httpsessioninfo to monitor unencrypted http traffic.

Using the above search, you should look to remove any common file names which you know are not malicious. For instance, if a Microsoft update server adds files to a specific folder with a long file name, you can exclude those files from the search with an exclude filter. Once you have removed these false positives from the network if they are appearing, you should expand the search time range to your full retention period. If there are very few files involved and you think that they are of a security significance, you should look to turn your search into a custom model and start firing detections for these filenames.

Suspicious File Paths

Some paths might be suspicious on your network, and warrant investigation, and a similar search should be used for this as for the suspicious file names example above.

You should collect a list of file paths you know are concerning in your org and create a search to monitor accesses against them. For this example below, let’s focus on any accesses made of files in /App/Data/Roaming/.

The search you would perform is: name:/ /App/Data/Roaming/.*/

This search will match any file accesses in that directory. In our system, we had a lot of legitimate accesses to them from 2 update servers. To reduce the noise from this search, find legitimate servers that you would expect to be accessing the folder you are concerned about, and click the zoom out icon beside its IP to exclude requests by that server.

Ja3 & Hassh

Ja3 & Hassh are fingerprinting methods which can recognize the source of SSL or SSH activity respectively based off available information from the cleartext packets sent before the encryption handshake is completed.

Ja3

Ja3 is a method to create SSL/TLS fingerprints which can be used to recognize the client or server in a given session. For example, a standard Tor client will have a Ja3 fingerprint of e7d705a3286e19ea42f587b344ee6865.

Ja3 fingerprints can indicate activity performed by the same application on multiple clients, and can also be used to check IOCs. This is not a foolproof solution, as it is possible for advanced attackers to alter their underlying fingerprints. For example, to check if TOR activity has been seen on your network, go to the metadata_ssl* stream, and search for: Ja3:e7d705a3286e19ea42f587b344ee6865

You can read more on Ja3 on the github profile, the community driven repository of Ja3 fingerprints, list of malicius JA3 fingerprints can be found on abuse.ch.

Hassh & HasshServer

Hassh uses similar logic to Ja3 in SSH connections, creating fingerprints of SSH connections, this can be used to spot where a specific client has been communicating over SSH with multiple different servers, and to see if any activity which appears is novel.

Hassh is particularly useful in tightly controlled environments. If there are any important sections in a network, then you could look to search specifically in that subnet’s SSH activity to see what Hassh are used there. Due diligence should be performed on these connections to make sure that none of this activity is malicious, and then each safe Hassh should be excluded from the search by clicking on the beside the field. Eventually, you should see no new Hassh in this subnet, and so you could save this search and activate it as a custom model (From manage -> custom models in the detect UI).

The Github community profile for Hassh lists many other uses from this data.

To enhance your security posture and ensure your organization is well-equipped to detect and respond to threats swiftly, detecting IoCs is essential. Vectra AI offers advanced solutions that integrate seamlessly with your existing security infrastructure, providing real-time detection and actionable intelligence. Contact us today to fortify your cyberdefense.