Bash Script to Locate log4j-core and delete JndiLookup.class

Posted: December 12th, 2021 | Author: | Filed under: IT Related | Tags: , , , , | 1 Comment »

Bash Script to Locate log4j-core and delete JndiLookup.class. Require root and zip. Not sure if this would help but here we go:

cd /
find . -print | grep 'log4j-core-.*\.jar' > /tmp/log4j-jar-files.txt
while IFS= read -r line; do
    echo "[*] Deleting JndiLookup.class from $line"
    zip -q -d "$line" org/apache/logging/log4j/core/lookup/JndiLookup.class
done < /tmp/log4j-jar-files.txt

Looking for the hashes for the vulnerable log4j-core JAR files? You can use them as inventory to indicate that u have vulnerable system(s). You may refer to this CSV:


In Response To FireEye’s Global DNS Hijacking Campaign

Posted: January 31st, 2019 | Author: | Filed under: IT Related | No Comments »

I’ve been asked on how do we assess our environment, if we are affected with the DNS hijacking as mentioned in “Global DNS Hijacking Campaign: DNS Record Manipulation at Scale”, here is a short HOWTO to guide you to verify against this threat in your environment, assuming you are looking into this from security operation/OSINT perspective and IT team is not involve.

  1. First you need to get/recon your own DNS record, focusing on A, and NS. You can go up to MX, but it was not part of the same campaign’s Tactics, Techniques and Procedures (TTP). You may want to use (but not limited to) the following tools to help you:
  2. Step #1 will give you the current record of the DNS. You can dive deeper and use historical or passive DNS records if you want to. I see no urgency to go more then 2017 (for this campaign)
  3. Remove the lines of record which contain your valid/known IP range
  4. Now you have the “suspicious” list to be verified. You may follow the change request (CR) audit processes to validate the IP resolution with DNS (IT) team, or you may directly verify them with the owner
  5. If you are not affected by the mentioned campaign, I believe you will still get some findings eg: old and un-maintained records, unauthorized change/CR, exposure of internal IP, etc

Happy hunting

Refreshing EK Hunting Technique (Enrichment) via TTP

Posted: January 2nd, 2017 | Author: | Filed under: IT Related | Tags: , , | 1 Comment »

Happy new year!

It has been a while since the last update.

Today I’ve saw an update in malware-traffic-analysis on RIG EK. Nothing new, but i asked myself if my old hunting technique is still relevant today, since i left EK hunting ‘industry’ 1 year++ ago. So i wrote a simple script to perform a quick check:

xanda:tmp xanda$ ./

I’ve found 2 IPs; (currently serving RIG, mentioned in malware-traffic-analysis blog) and is not yet serving anything malicious, but my prediction, it will be serving RIG EK in/within the next 7 days.

Some tips on this fingerprinting technique:

  1. Based on the initial IP found, look for the IP range assigned to the same ASN, in this case
  2. Identify the HTTP header response from the known bad IP, and use it to fingerprint the rest.
  3. Based from my experience, 1 batch of EK server setup will have similar (or almost similar) HTTP header response, and some EK will use 1 subnet for 1 batch (but not necessarily)
  4. EK server will always (mostly) be dedicated. If you found historical pDNS record on that IP, verify (with dig/nslookup) for the current IP resolved by the domain(s). For example; has 3 historical pDNS record, but at the moment, 1 of the domain has expired, and another 2 domains are now pointing to different IP(s).
  5. This method will only works if the “scanned” hosts are alive at that particular moment

Hope it helps. Happy hunting

Locky DGA Threat Actor(s)

Posted: March 7th, 2016 | Author: | Filed under: IT Related | Tags: , , | No Comments »

While “Locky” is still hot. Let me write a small update on my findings.

Based on the (new) DGA algorithm published in Forcepoint’s blog post, with the help of pyLockyDGA project, I’ve performed a minor patch on the python code to allow me to automate some stuff.

I quick run for 1 month DGA lead me to the following results (filtered to see only registered and resolved domains):

Whois record all of those domains contains these 2 emails


And from a quick search, is a known threat actor involved with several botnet CnC domains earlier and also mentioned several legal notices. I also found a few domains registered by has been sinkholed by several law enforcement and regulators. With those findings, i simply conclude that those emails can be (potentially) associated directly or indirectly with Locky. (unless they are security researchers who registered the domains for sinkhole/research purpose)

IP resolved by those domains in the list above are:


Thanks to ; domains registered by can be found here [compact whois record] and domains registered by can be found here [compact whois record]

Copy and paste version of the IOCs is available here

Any error or mislead information? Please let me know by email or in the comment. Thanks 🙂

How Did I Find APT16 New Infa with VirusTotal pDNS and a lil Bit of Luck

Posted: January 25th, 2016 | Author: | Filed under: IT Related | Tags: , | No Comments »

[Quick and short update]

Last couple of weeks, I was reading the The EPS Awakens – Part 2 blog entry from FireEye and found this one IP,, was previously used as their C2 server. I used VirusTotal IP information, these few domains appeared:


I went and check more information on each domain listed and found new infra (IPs) being used: domain information
2015-07-01 domain information
2015-07-01 domain information
2015-07-01 domain information

I quickly check the server HTTP response header and this is what I’ve found that they are all the same:

HTTP/1.1 403 Forbidden
Server: nginx/1.6.2
Date: (current time of check)
Content-Type: text/html
Content-Length: 168
Connection: keep-alive

Okay, we already have,,, Lets just quickly perform the HTTP response header loop for the whole /24 subnet (or maybeee i lil bit more). This is the result:

Okay i’m running out of time, my kids are waiting for me outside.

From my quick check on the domain resolved to the IP range – , I can safely assume that those are APT16 new infra. But I not really confident to attribute –, but those IPs in that range, and domains revolved to that range, are fishy!

Happy hunting