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:

version,md5,sha1,sha256
log4j-core-2.0-beta9.jar,152ecb3ce094ac5bc9ea39d6122e2814,678861ba1b2e1fccb594bb0ca03114bb05da9695,dcde6033b205433d6e9855c93740f798951fa3a3f252035a768d9f356fde806d
log4j-core-2.0-rc1.jar,088df113ad249ab72bf19b7f00b863d5,4363cdf913a584fe8fa72cf4c0eaae181ef7d1eb,db3906edad6009d1886ec1e2a198249b6d99820a3575f8ec80c6ce57f08d521a
log4j-core-2.0-rc2.jar,de8d01cc15fd0c74fea8bbb668e289f5,2e8d52acfc8c2bbbaa7baf9f3678826c354f5405,ec411a34fee49692f196e4dc0a905b25d0667825904862fdba153df5e53183e0
log4j-core-2.0.jar,cd70a1888ecdd311c1990e784867ce1e,7621fe28ce0122d96006bdb56c8e2cfb2a3afb92,85338f694c844c8b66d8a1b981bcf38627f95579209b2662182a009d849e1a4c
log4j-core-2.0.1.jar,fbfa5f33ab4b29a6fdd52473ee7b834d,895130076efaf6dcafb741ed7e97f2d346903708,a00a54e3fb8cb83fab38f8714f240ecc13ab9c492584aa571aec5fc71b48732d
log4j-core-2.0.2.jar,8c0cf3eb047154a4f8e16daf5a209319,13521c5364501478e28c77a7f86b90b6ed5dbb77,c584d1000591efa391386264e0d43ec35f4dbb146cad9390f73358d9c84ee78d
log4j-core-2.1.jar,8d331544b2e7b20ad166debca2550d73,31823dcde108f2ea4a5801d1acc77869d7696533,8bdb662843c1f4b120fb4c25a5636008085900cdf9947b1dadb9b672ea6134dc
log4j-core-2.2.jar,5e4bca5ed20b94ab19bb65836da93f96,c707664e020218f8529b9a5e55016ee15f0f82ac,c830cde8f929c35dad42cbdb6b28447df69ceffe99937bf420d32424df4d076a
log4j-core-2.3.jar,110ab3e3e4f3780921e8ee5dde3373ad,58a3e964db5307e30650817c5daac1e8c8ede648,6ae3b0cb657e051f97835a6432c2b0f50a651b36b6d4af395bbe9060bb4ef4b2
log4j-core-2.4.jar,0079c907230659968f0fc0e41a6abcf9,0d99532ba3603f27bebf4cdd3653feb0e0b84cf6,535e19bf14d8c76ec00a7e8490287ca2e2597cae2de5b8f1f65eb81ef1c2a4c6
log4j-core-2.4.1.jar,f0c43adaca2afc71c6cc80f851b38818,a5334910f90944575147fd1c1aef9f407c24db99,42de36e61d454afff5e50e6930961c85b55d681e23931efd248fd9b9b9297239
log4j-core-2.5.jar,dd0e3e0b404083ec69618aabb50b8ac0,7ed845de1dfe070d43511fab321784e6c4118398,4f53e4d52efcccdc446017426c15001bb0fe444c7a6cdc9966f8741cf210d997
log4j-core-2.6.jar,5523f144faef2bfca08a3ca8b2becd6a,a7cb258b9c36f49c148834a3a35b53fe73c28777,df00277045338ceaa6f70a7b8eee178710b3ba51eac28c1142ec802157492de6
log4j-core-2.6.1.jar,48f7f3cda53030a87e8c387d8d1e4265,2b557bf1023c3a3a0f7f200fafcd7641b89cbb83,28433734bd9e3121e0a0b78238d5131837b9dbe26f1a930bc872bad44e68e44e
log4j-core-2.6.2.jar,472c8e1fbaa0e61520e025c255b5d168,00a91369f655eb1639c6aece5c5eb5108db18306,cf65f0d33640f2cd0a0b06dd86a5c6353938ccb25f4ffd14116b4884181e0392
log4j-core-2.7.jar,2b63e0e5063fdaccf669a1e26384f3fd,a3f2b4e64c61a7fc1ed8f1e5ba371933404ed98a,5bb84e110d5f18cee47021a024d358227612dd6dac7b97fa781f85c6ad3ccee4
log4j-core-2.8.jar,c6d233bc8e9cfe5da690059d27d9f88f,2be463a710be42bb6b4831b980f0d270b98ff233,ccf02bb919e1a44b13b366ea1b203f98772650475f2a06e9fac4b3c957a7c3fa
log4j-core-2.8.1.jar,547bb3ed2deb856d0e3bbd77c27b9625,4ac28ff2f1ddf05dae3043a190451e8c46b73c31,815a73e20e90a413662eefe8594414684df3d5723edcd76070e1a5aee864616e
log4j-core-2.8.2.jar,4a5177a172764bda6f4472b94ba17ccb,979fc0cf8460302e4ffbfe38c1b66a99450b0bb7,10ef331115cbbd18b5be3f3761e046523f9c95c103484082b18e67a7c36e570c
log4j-core-2.9.0.jar,fab646257f945b0b2a7ce3e1c3e3ce5f,052f6548ae1688e126c29b5dc400929dc0128615,fb086e42c232d560081d5d76b6b9e0979e5693e5de76734cad5e396dd77278fd
log4j-core-2.9.1.jar,942f429eacb8015e18d8f59996cfbee6,c041978c686866ee8534f538c6220238db3bb6be,dc435b35b5923eb05afe30a24f04e9a0a5372da8e76f986efe8508b96101c4ff
log4j-core-2.10.0.jar,dc99011f047e63dcc741b5ab68d116db,c90b597163cd28ab6d9687edd53db601b6ea75a1,22b58febab566eddd5d4863f09dad4d5cc57677b6d4be745e3c6ce547124a66d
log4j-core-2.11.0.jar,2abec2ce665e0d529a3f28fffbbb2dd3,e6b751e02120c08702d98750f6a80bc25343b7f5,c32029b32da3d8cf2feca0790a4bc2331ea7eb62ab368a8980b90c7d8c8101e0
log4j-core-2.11.1.jar,b2242de0677be6515d6cefbf48e7e5d5,592a48674c926b01a9a747c7831bcd82a9e6d6e4,a20c34cdac4978b76efcc9d0db66e95600bd807c6a0bd3f5793bcb45d07162ec
log4j-core-2.11.2.jar,c8bd8b5c5aaaa07a3dcbf57de01c9266,6c2fb3f5b7cd27504726aef1b674b542a0c9cf53,d4748cd5d8d67f513de7634fa202740490d7e0ab546f4bf94e5c4d4a11e3edbc
log4j-core-2.12.0.jar,5c527821d1084a7ef3e03d40144ff532,01723837573e4c5dbc8840f9f6e8f79b245b94bb,8818f82570d3f509cfb27c209b9a8df6f188857b7462951a61a137be09cf3463
log4j-core-2.12.1.jar,0138ba1c191d5c754fd0e3c3a61c0307,4382e93136c06bfb34ddfa0bb8a9fb4ea2f3df59,885e31a14fc71cb4849e93564d26a221c685a789379ef63cb2d082cedf3c2235
log4j-core-2.13.0.jar,b71a13fd5df251694fca116240003b22,57b8b57dac4c87696acb4b8457fd8cbf4273d40d,82e91afe0c5628b32ae99dd6965878402c668773fbd49b45b2b8c06a426c5bbb
log4j-core-2.13.1.jar,d365e48221414f93feef093a1bf607ef,533f6ae0bb0ce091493f2eeab0c1df4327e46ef1,88ebd503b35a0debe18c2707db9de33a8c6d96491270b7f02dd086b8072426b2
log4j-core-2.13.2.jar,0ac5b3e6e69ba7765683798e669a30b2,8eb1fc1914eb2550bf3ddea26917c9a7cbb00593,268dc17d3739992d4d1ca2c27f94630fb203a40d07e9ad5dfae131d4e3fa9764
log4j-core-2.13.3.jar,cc7d55ed69cc5fd34035b15c6edf79a0,4e857439fc4fe974d212adaaaa3b118b8b50e3ec,9529c55814264ab96b0eeba2920ac0805170969c994cc479bd3d4d7eb24a35a8
log4j-core-2.14.0.jar,862c00b2e854f9c0f1e8d8409d23d899,e257b0562453f73eabac1bc3181ba33e79d193ed,f04ee9c0ac417471d9127b5880b96c3147249f20674a8dbb88e9949d855382a8
log4j-core-2.14.1.jar,948dda787593340a7af1a18e328b7b7f,9141212b8507ab50a45525b545b39d224614528b,ade7402a70667a727635d5c4c29495f4ff96f061f12539763f6f123973b465b0

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$ ./loop.sh 109.234.36.0
109.234.36.133
109.234.36.210
DONE!

I’ve found 2 IPs; 109.234.36.133 (currently serving RIG, mentioned in malware-traffic-analysis blog) and 109.234.36.210. 109.234.36.210 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 109.234.36.0/24
  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; 109.234.36.210 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):

qxicsfgofp.in
yqbcarhmtuskpq.be
taflicbfuos.pw
yqbcarhmtuskpq.be
taflicbfuos.pw
afcnikg.be

Whois record all of those domains contains these 2 emails

  • jgou.veia@gmail.com
  • tech1@101domain.com

And from a quick search, jgou.veia@gmail.com 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 tech1@101domain.com 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:

  • 195.22.28.196
  • 195.22.28.197
  • 195.22.28.198
  • 195.22.28.199

Thanks to whoxy.com ; domains registered by jgou.veia@gmail.com can be found here [compact whois record] and domains registered by tech1@101domain.com 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, 121.127.249.74, was previously used as their C2 server. I used VirusTotal IP information, these few domains appeared:

2015-07-01 frppl.com
2015-07-01 jrjfj.com
2015-07-01 pjntx.com
2015-07-01 vzflx.com
2015-07-01 yeaqm.com

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

frppl.com domain information
2015-12-21 123.60.73.10
2015-07-01 121.127.249.74
 
jrjfj.com domain information
2015-12-21 123.60.73.8
2015-07-01 121.127.249.74
 
pjntx.com domain information
2015-12-28 123.60.73.9
2015-07-01 121.127.249.74
 
yeaqm.com domain information
2015-12-27 123.60.73.6
2015-07-01 121.127.249.74

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 123.60.73.6, 123.60.73.8, 123.60.73.9, 123.60.73.10. Lets just quickly perform the HTTP response header loop for the whole /24 subnet (or maybeee i lil bit more). This is the result:

123.60.73.1
123.60.73.2
123.60.73.3
123.60.73.4
123.60.73.5
123.60.73.6
123.60.73.7
123.60.73.8
123.60.73.9
123.60.73.10
123.60.73.11
123.60.73.12
123.60.73.13
123.60.73.14
123.60.73.15
123.60.73.16
123.60.73.17
123.60.73.18
123.60.73.19
123.60.73.21
123.60.73.22
123.60.73.23
123.60.73.24
123.60.73.25
123.60.73.26
123.60.73.27
123.60.73.28
123.60.73.29
123.60.73.30
123.60.73.31
123.60.73.32
123.60.73.33
123.60.73.34
123.60.73.35
123.60.73.36
123.60.73.37
123.60.73.38
123.60.73.39
123.60.73.40
123.60.73.41
123.60.73.42
123.60.73.43
123.60.73.44
123.60.73.45
123.60.73.46
123.60.73.47
123.60.73.48
123.60.73.49
123.60.73.50
123.60.73.51
123.60.73.52
123.60.73.53
123.60.73.54
123.60.73.55
123.60.73.56
123.60.73.57
123.60.73.58
123.60.73.59
123.60.73.60
123.60.73.61
123.60.74.1
123.60.74.2
123.60.74.3
123.60.74.4
123.60.74.5
123.60.74.6
123.60.74.7
123.60.74.8
123.60.74.9
123.60.74.10
123.60.74.11
123.60.74.12
123.60.74.13
123.60.74.14
123.60.74.15
123.60.74.16
123.60.74.17
123.60.74.18
123.60.74.19
123.60.74.20
123.60.74.21
123.60.74.22
123.60.74.23
123.60.74.24
123.60.74.25
123.60.74.26
123.60.74.27
123.60.74.28
123.60.74.29
123.60.74.30
123.60.74.31
123.60.74.32
123.60.74.33
123.60.74.34
123.60.74.35
123.60.74.36
123.60.74.37
123.60.74.38
123.60.74.39
123.60.74.40
123.60.74.41
123.60.74.42
123.60.74.43
123.60.74.44
123.60.74.45
123.60.74.46
123.60.74.47
123.60.74.48
123.60.74.49
123.60.74.50
123.60.74.51
123.60.74.52
123.60.74.53
123.60.74.54
123.60.74.55
123.60.74.56
123.60.74.57
123.60.74.58
123.60.74.59
123.60.74.60
123.60.74.61

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 123.60.73.1 – 123.60.73.61 , I can safely assume that those are APT16 new infra. But I not really confident to attribute 123.60.74.1 – 123.60.74.61, but those IPs in that range, and domains revolved to that range, are fishy!

Happy hunting