Autodesk TLS SNI alerts ( 2034098 )

I am seeing alerts on SID 2034098 ET HUNTING Observed AutoDesk Domain in TLS SNI (api .autodesk .com) from a few machines in our Engineering school where we expect machines to be running AutoCAD. The actual SNI is developer.api.autodesk.com and the destination IPs are all AWS and lastly I can not find any other suspicious traffic from any of the machines.

My instinct is to ignore these but one thing that is a bit odd is that the alerts are occurring through the whole 24 hours.

The rule has no reference so I have no idea how to tell if it is a cause for concern or not.

Anyone know what the actual issues is?

Hi Russell,

I’m not familiar with this rule but if you search for proofpoint and the SID 2034098 you’ll find a page dated 4 October, 2021: Daily Ruleset Update Summary 2021/10/04 | Proofpoint US

That page contains the rules released that date and contain the following URL for sharing issues, feedback and requests:
https://feedback.emergingthreats.net/feedback

1 Like

Hi Russell,

HUNTING (Suricata 5 ruleset) or INFO/POLICY (Suricata 4/Snort ruleset) are not directly tied to malicious activity. Rules in the HUNTING/INFO/POLICY categories are based on traffic that could be of interest depending on the environment Suricata and the rules are deployed in.

With specific regard to the sid (2034098) you mention, we (Emerging Threats/Proofpoint) saw Autodesk being used as part of an infection chain. In an effort to give folks as much insight into traffic going across their networks we made a HUNTING/INFO rule around this.

In environments where one would not expect to see autodesk endpoints being used, this would be of interest. In other environment it would probably be too noisy. But it gives a point of investigation for activity that could end up being malicious.

With an unknown number of people that have MiTM/SSL decrypt available we try to have rules that cover the capabilities of everyone. Meaning, we usually try to have a very specific signature in the case where SSL decrypt is available, for environments that do not have SSL decrypt, we try to provide SSL/TLS sigs and/or DNS signatures. The DNS/SSL/TLS signatures are obviously much more generic but is the best we can do in some cases.

As Jeff mentioned, feel free to hit us up via the feedback portal. Hopefully that helps and I apologize for the delay in response.

JT

Thanks for the clarification! And yes, I will use the feedback portal for rule queries in future. I used to use the mailing lists…

I have been using Suricata since (IIRC) the beta for version 1 but lately have been neglecting it due to staff shortages. So it is good to know what the threat hunting category is for. I more or less figured it out before.

What I will probably do is reduce the severity rating of these rules as they are rather noisy but they will still come up if we start searching for for stuff by IP. Or, better still, simply modify the ES filter for the “IMPORTANT Alerts” dashboard to ignore them. I do this with all the IP based rules as we see hits on them all the time and have yet to find anything interesting upon investigation but if there is ever a problem with a machine it is very useful to know that it has been talking to something that has hosted a CnC.

1 Like