有时候我会在自己的PC机上启一个dns代理服务器，用来记录本机所有的DNS查询，收集各大公司的域名。
启动脚本的时候，会自动配置主DNS服务器到127.0.0.1，通过netsh命令实现即可：
netsh interface ipv4 set dnsservers "本地连接" static 127.0.0.1 netsh interface ipv4 add dns name="本地连接" addr="8.8.8.8" index=2
以上将主dns设置为127.0.0.1，辅dns服务器设置为8.8.8.8。
同理，在代理程序中止的时候，又自动将DNS设置还原为原始IP。
昨天清理磁盘，整理旧文件的时候，轻信直接打开了wooyun zone里某位白帽子分享的工具，一时大意，中马了。
PC机上有个360安全卫士，也没有一丁点的提示。。。（这木马过360的）
随后我在修改subDomainsBrute的时候，抓dns query，惊讶地发现，出现了一个3322.org的域名，并且对应记录是不存在的，如下图：
以前玩远控木马的同学可能知道，3322.0rg，花生壳之类的，常常被用来木马在内网反向上线的。所以，这个地方十分不正常，这让我意识到，有较大的几率已经中马了。
用360安全卫士扫描，没有发现任何木马和危险项，之前也提到了，这个木马是过360的。
现在的问题是，如何抓到这个木马，我绕了一个弯子，因为我想从dns query入手来查找（正确的做法是打开进程查看器，逐个进程检查）：
在抓dns query源进程受阻的情况下，我想到，既然木马想访问likang.3322.org，而这个域名又不存在。 那么我应该可以欺骗它去访问我自己的服务器，我修改hosts文件，添加：
11.22.33.44 likang.3322.org
这个时候，我应该可以抓到访问likang.3322.org的其他请求了。
我用smartsniff抓包，发现有到目标11.22.33.44的http request，木马会请求http://likang.3322.org/ip.txt，看起来像是一个DDOS木马，下载攻击目标的。
这个时候我还是没抓到进程，对应的http://likang.3322.org/ip.txt文件并不存在，http request一瞬间就结束了，tcp查看工具因为刷新频率的原因，还看不到对应的进程。
于是我在11.22.33.44上python起了一个http server，并且让get请求hang住，sleep 30s，最终抓到了对应的进程：
如图，QQ进程：
总结一下，上面也说到，正确的做法，应该是查看进程列表，然后逐个检查进程是否正常，从 启动时间 | 可执行文件的创建日期 等特征对比。
绕个弯子，换了个思路。 🙂
在windows下写python的web漏扫脚本，有时候需要观察http连接数。
可以使用如下批处理：
@echo off :count echo|set /p="Num of HTTP Connections: " & netstat -na | find /C ":80" timeout 3 > nul GOTO count
将上述脚本保存为http_conn.bat，在扫描时可以简单地监视http连接：
为答谢广大白帽子对71SRC的支持和厚爱，特举行一次为期3个月的金币翻倍活动。
2016/4/12 – 2016/6/30
在上述时间内报告漏洞，可享受双倍金币奖励！
71SRC收到的所有有效漏洞（已确认），金币奖励翻倍:
a) 低危漏洞： 分值 1-2，金币系数3，单个漏洞奖励 3 – 10 金币
b) 中危漏洞： 分值 3-5，金币系数4，单个漏洞奖励 12 – 50 金币
c) 高危漏洞： 分值 6-9，金币系数10，单个漏洞奖励 60 – 200 金币
d) 严重漏洞： 分值 9-12，金币系数20，单个漏洞奖励 180 – 500 金币
同时，对于攻击成本很低，但能够影响到海量用户数据、影响VIP会员增值业务、影响支付业务的严重漏洞和威胁情报，原有的双倍积分计划可以叠加。
活动相关规则，欢迎加入QQ群参与讨论 71SRC白帽子交流群 130763408 （请备注在71SRC平台的ID）
很久没有写博客了，不太容易安静下来，做一些简单的总结。希望2016年可以多记录一些零散的想法。
今天简单聊一下 RTLO的小问题。
RTLO是一个8238的Unicode字符，它的作用是让紧跟在后面的字符串倒序： http://www.codetable.net/decimal/8238
可以用来欺骗用户打开可执行文件（钓鱼攻击），或者欺骗后端应用的检查机制。
例如，我这里有一个可执行文件，文件名是 u’aaaa\u202eFDP.exe’ 的文件，202e是
>> hex(8238) '0x202e'
那么windows用户在资源管理器中看到的文件名将显示为 aaaaexe.PDF，如果这个exe的图标正好PDF的图标，可能会欺骗用户点击执行。
我示例将cmd.exe重命名为u’aaaa\u202eFDP.exe’ ，python中执行
>> os.rename('cmd.exe', u'aaaa\u202eFDP.exe')
用户在资源管理器中看到的效果就是aaaaexe.PDF（我这里特意大写了PDF）：
不过，可以注意到，文档类型那一栏，依然是“应用程序”。而且一般的安全工具也能拦截这种欺骗攻击。
本文参考链接： https://blog.malwarebytes.org/online-security/2014/01/the-rtlo-method/
上周兴冲冲地申请了个wosign的免费SSL证书，用在博客 https://www.lijiejie.com
用了几天之后，发现性能实在无法接受。启用SSL后页面访问明显变慢太多了。
而且在某些网络环境下，博客直接无法访问：比如北京比较坑爹的鹏博士宽带，或者移动4G环境。
SSL handshake耗费了太多时间，而加密网页还需要消耗额外的CPU资源。
无奈，只好又禁用了SSL，把所有https链接全部301重定向到http。待Google和百度重新收录。
如果主机在内地，网络和性能都不错，还是可以考虑在登录等敏感操作的功能上应用SSL的，避免敏感信息在网络中明文传输。
虽然选择了停用SSL，但毕竟搜索引擎已收录一些https页面。所以临时地，443端口对应的VirtualHost还必须保留SSLEngine启用状态。
以便进行urlRedirect.
禁用SSL之后，发现博客访问起来又恢复顺畅了！
<VirtualHost *:443>
ServerAdmin my[at]lijiejie.com
ServerName www.lijiejie.com
DocumentRoot /some_folder
Redirect permanent / https://www.lijiejie.com/
SSLEngine on
SSLOptions +StrictRequire
SSLCertificateFile /some_folder/www.lijiejie.com.crt
SSLCertificateKeyFile /some_folder/www.lijiejie.com.key
SSLCertificateChainFile /some_folder/1_root_bundle.crt
</VirtualHost>
<VirtualHost *:80>
ServerAdmin my[at]lijiejie.com
ServerName www.lijiejie.com
DocumentRoot /some_folder
#SSLEngine on
#SSLOptions +StrictRequire
#SSLCertificateFile /some_folder/www.lijiejie.com.crt
#SSLCertificateKeyFile /some_folder/www.lijiejie.com.key
#SSLCertificateChainFile /some_folder/1_root_bundle.crt
<Directory /some_folder/>
Options -Indexes
AllowOverride All
Order allow,deny
allow from all
</Directory>
</VirtualHost>