Let’s Defend: Event 75 – SOC105 – Requested T.I. URL address – Write-up (Advertisement)

Gooood day fellow readership. Since many of you liked my last post about the letsdefend.io-platform, I got you another one today! So without further ado: Let’s defend!

The event

Today’s alert triggered the SOC rule 105 – Requested T.I. URL address. So apparently the hostname „MarksPhone“ (IP: requested an URL listed in our Threat Intelligence Data. The incident happened on March 7, 2021 at 5:47pm. Further information:

  • The destination IP address is „“, destination hostname is „bit.ly“
  • The requested URL is „https://bit.ly/TAPSCAN“
  • The request was not blocked by the firewall („allowed“)

Threat Intel: What is Bitly?

After taking a quick look at the Threat Intel Data, we can see „bit.ly“ being listed as „spam“ with a score of 2.0, so the triggered alert was correct. Bitly provides a tool to shorten URLs, see https://support.bitly.com/hc/en-us/articles/230895688-What-is-Bitly- . Adversaries may take advantage of this tool to trick victims into clicking an URL generated with an URL shortener. The main goal is to hide the actual (malicious) URL behind that shortened bit.ly-URL.

URL request

Before, we verified that Bitly was listed in our Threat Intelligence Data. Now we have to verify, the URL was requested by MarksPhone. In the Log-Area we search for „bit.ly“ and find theset to results. The second result is exactly the date and IP-data we found in our alert. So, the request was real, too.

Starting the playbook

After approving the correctness of the alert, let’s switch to the fun part: The playbook. The first task is to analyze the data for maliciousness. The playbook leads us to check the URL on several free online analyzing tools, like any.run (I can highly recommend, awesome tool). The main strength of any.run and Hybrid-Analysis is analyzing files, so for URLs my favorites for this case are VirusTotal and URLScan.

VirusTotal, Google PlayStore and more…

VirusTotal result of the bit.ly-URL

Well, Comodo and CRDF flagged the requested URL MarksPhone visited as malicious. We do not find further info on the community tab. Let us keep the tags in mind and move on to the next tool, urlscan.io:

urlscan.io result

I really love checking URLs with urlscan.io getting so much information out of it. (Let me know if you have any other recommended tools!) Urlscan provides us a Screenshot of the redirected request (useful!) so we do not have to visit the URL ourself. In addition to that we see some live informations from ressources like whois or traceroute. As you can see, there is a lot more, but I cannot cover all the features in this post. 😉

In this case, urlscan.io does not classifies this URL as malicious, nor do I see any prove of maliciousness. Let us review the Google Play Store URL the shortened URL redirects us to:

VirusTotal result for Google Play Store URL

Okay, the Google Play Store URL looks clean. Even though VirusTotal showed two malicious records on vendors, at this point I personally think this URL is not malicious. The lifetime membership at shodan.io comes handy for getting more information about the IP address:

shodan result for destination ip address

The IP address belongs to Bitly Inc, so no malicous evidence here. Since VirusTotal did not provide further data why the vendors flagged this URL, we visit the vendors directly:

Valkyrie Verdict result of URL scan

On Comodo’s Valkyrie Verdict the URL is now listed as „Safe“. The CRDF homepage did not include any search functionality (maybe I just did not find it).


Just to be sure (and because Let’s Defend offers this feature), let’s take a look at the endpoint, MarksPhone:


I checked all the details (Browser History, Command History, Network Connections and Process List) and there were no logs available. No malicious nor suspicious indicators could have been found.

Gathering the results

In order to decide, whether the URL is malicious or not, we collected following information:

  • Shortened bit.ly-URL redirects to Google Play Store
  • Two vendors listed the URL as malicious on VirusTotal
  • One of these two vendors now listed the URL as „safe“
  • urlscan.io shows no evidence of malicious content
  • no other indicators for maliciousness found

Well, in this case we decide the URL is not malicious and we fill in the artifacts. Do not forget to provide your summary as an Analyst Note:

Closing the case

Okay, we finished the playbook and now let’s head to the monitoring page again to close the case.

summary „close alert“

To be honest, this one is quite tricky and I would accept arguments for both choices. It is somewhat of a „True Positive“, because the alert triggered the rule correctly. On the other hand there was no evidence of malicious activity and since I think this is how Let’s Defend works, I chose „False Positive“ for this case.

True or false?

After closing the case, we can review our performance. There are cases where you have to answer a lot more questions in the playbook, but we will cover some of these later:

Well done, we got full points from this case. You may leave your notes blank here, but I would always recommend filling these in the real world, so your colleagues can relate to your decision.

Also DO NOT FORGET to share your success on twitter by clicking this fancy little blue bird. This helps the people at Let’s Defend a lot! Stay tuned for more write-ups!

Nach oben scrollen