The risk of oversharing during incident response and what you should do with XSOAR Engines

January 23, 2023 joerg Uncategorized 0

The risk of oversharing during incident response and what you should do with XSOAR Engines

Whenever you investigate on an potential incident you will run into the chance that you are simply over sharing information with the outside world or even the attacker by enriching the context data, let me explain how to reduce the risk using XSOAR

Using the rasterize function of XSOAR

How the problem occurs

Accidental over sharing happens all the time, some are very obvious like taking all the threat intelligence you extracted from data and putting them into any 3rd party platform (Virustotal, X Force Exchange, etc), we know that adversaries look out for certain hashes of malware they have created.

Other exposures happen not so obvious. One good example is the way an analyst will maybe click a url to verify if it is malicious or you use a tool like a Threat Intelligence Platform, a SIEM or Incident Response Platform to analyse the url and maybe screenshot it.

There are at least three problems with this

  • The URL belongs to a web server (obvious) and an attacker with access to the log files can easily monitor if the URL was accessed
  • In addition the URL maybe unique to your environment, so the attacker also sees which of his phishing/spam emails actually gut accessed
  • The IP address which is logged by the attacker will most likely be part of your infrastructure, so the access can be directly linked back to you

This, in the worst case, shows the attacker that his attempt actually failed and that he needs to change tactics.

Just in case you ask why: Most analyst tools or platforms will have a large difference in how they open a URL, you guessed right, the User Agent, with automated scripts we would see something like

"python-requests/2.28.1"
"curl/7.47.0"

Which are maybe the most prominent examples of what an automation would use, while a legit (successful phishing) should show something like

"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36"
"Mozilla/5.0 (Android 13; Mobile; rv:108.0) Gecko/108.0 Firefox/108.0"
"Mozilla/5.0 (Linux; Android 13; SM-G781B) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Mobile Safari/537.36"

Again, while the difference is obvious, it will show an attacker who monitors his ongoing phishing attempts if a url was discovered or not.

The second part is the source of the request. As you may know, every http communication will leave behind a client IP, this could be something like

GET https blog.johest.de "/" [Client 143.178.xx.xx]
or
GET https blog.johest.de "/" [Client 34.83.2.xx]

In the worst case, this IP address will expose your origin. So the attacker will be able to even identify which company detected the phishing email by simple tying the client IP to the company he targeted. As attackers are not stupid, they will use the same tools as we blue teamers do: Whois, IP Info, etc.

Mitigating the risk with XSOAR Engines

The Client IP example above was actually done by the same platform, Palo Alto Networks Cortex XSOAR.

But one will be tight back to a T-Mobile DSL network, basically from my home office and the other belongs to Google Cloud. I believe it is understandable that I rather expose a Google Cloud IP address to the people sending me Spam and Phishing emails rather than my home network address.

URL Screenshots in XSOAR are done via a simple integration called rasterize

Using the rasterize function of XSOAR

Rasterize will take any url you give it and go out to make a screenshot of it. This also exists for Emails, PDF and such, so you can visualize an Email as a picture without the issue of someone clicking a link or some code being executed while doing so.

The last point you see in the configuration above is also the important one. In my case I make use of an engine called dcs1 (pardon my naming skills, it stands for datacenter server 1).

So in XSOAR I did set up this Engine. An Engine is something you can imagine like a proxy, it will work with every integration and it will make sure that the actually task or query is performed on the engine instead of the server itself. While this is intended to reach hidden or unreachable networks, such an Engine within a public cloud provider can help you not to over share during the investigation.

Another positive point of XSOAR is that rasterize will already use a common User Agent, which in addition lowers the risk of the investigation being discovered by the adversary.

Thanks for reading to the end, be excellent to each other