This full-featured system analyzing tool lets you take a sneak peek at everything that's going on in your system, from currently active processes to installed drivers, including also network collections, startup applications and Internet Explorer add-ons, if you have any. You can end any active process or delete items from the startup menu, to name a couple of examples. System Explorer has the possibility to obtain more information about each process from google, or check it for virus with an online anti-virus tool. The program includes loads of other interesting features. Version 1.5 includes support for external and internal plugins, filtering support to lists, and new plugin adds security enhancements.
Investigating a web-based intrusion can be a daunting task, especially when you have no information other than knowing it was web-based. It is easy to waste precious time digging through megabytes, perhaps even gigabytes, of log files trying to locate suspicious activity. Often this search turns up little useful evidence.
Consider this scenario: an e-commerce site receives several reports from customers about unauthorized orders on their accounts. They suspect that someone has compromised their web-based ordering system so they gather the log files from several different IIS web servers. They have the dates and times of the orders, but the corresponding IP addresses in the log files turn out to be anonymous proxies used by the suspect. Searching for activity from those IP addresses in the log files turns up nothing. Browsing through the raw log files for those dates also turns up nothing. Somehow, someone found a flaw in the ordering system but he or she could have discovered the flaw months before exploiting it. Tracking down the flaw and IP addresses used by the suspect seems impossible. But there are techniques that can facilitate log file forensics. The purpose of this article is to demonstrate log file forensics of IIS logs using SQL queries with Microsoft's LogParser tool.
IIS Log Fields
The first step is to prepare for security incidents by logging as much information as possible. IIS can log a significant amount of information about each web request, but many of the available log fields are not enabled by default. To enable full logging, open the Internet Services Manager and edit the Extended Logging Properties to include all available log fields. Much of this information has some forensics value as shown in Table 1.
Table 1: IIS Log Fields
Field Name
Description
Uses
Date (date)
The date of the request.
Event correlation.
Time (time)
The UTC time of the request.
Event correlation, determine time zone, identify scanning scripts.
Client IP Address (c-ip)
The IP address of the client or proxy that sent the request.
Identify user or proxy server.
User Name (cs-username)
The user name used to authenticate to the resource.
Identify compromised user passwords.
Service Name (s-sitename)
The W3SVC instance number of the site accessed.
Can verify the site accessed if the log files are later moved from the system.
Server Name (s-computername)
The Windows host name assigned to the system that generated the log entry.
Can verify the server accessed if the log files are later moved from the system.
Server IP Address (s-ip)
The IP address that received the request.
Can verify the IP address accessed if the log files are later moved from the system or if the server is moved to a new location.
Server Port (s-port)
The TCP port that received the request.
To verify the port when correlating with other types of log files.
Method (cs-method)
The HTTP method used by the client.
Can help track down abuse of scripts or executables.
URI Stem (cs-uri-stem)
The resource accessed on the server.
Can identify attack vectors.
URI Query (cs-uri-query)
The contents of the query string portion of the URI.
Can identify injection of malicious data.
Protocol Status (sc-status)
The result code sent to the client.
Can identify CGI scans, SQL injection and other intrusions.
Win32 Status (sc-win32-status)
The Win32 error code produced by the request.
Can help identify script abuse.
Bytes Sent (sc-bytes)
The number of bytes sent to the client.
Can help identify unusual traffic from a single script.
Bytes Received (cs-bytes)
The number of bytes received from the client.
Can help identify unusual traffic to a single script.
Time Taken (time-taken)
The amount of server time, in milliseconds, taken to process the request.
Can identify unusual activity from a single script.
Protocol Version (cs-version)
The HTTP protocol version supplied by the client.
Can help identify older scripts or browsers.
Host (cs-host)
The contents of the HTTP Host header sent by the client.
Can determine if the user browsed to the site by IP address or host name.
User Agent (cs(User-Agent))
The contents of the HTTP User-Agent header sent by the client.
Can help uniquely identify users or attack scripts.
Cookie (cs(Cookie))
The contents of the HTTP Cookie header sent by the client.
Can help uniquely identify users.
Referer (cs(Referer))
The contents of the HTTP Referer header sent by the client.
Can help identify the source of an attack or see if an attacker is using search engines to find vulnerable sites.
While I normally recommend logging all fields, the actual fields you choose to log should be based on a balance between forensics capabilities and disk space.
Custom Logging
IIS does provide many log fields, but there may be other fields you wish to record. For example, if the request comes from a proxy server, you may want to see if the proxy server sends the client's real IP address through other HTTP headers. For example, some proxy servers add the "X-Forwarded-For" header containing the client's real IP address.
IIS has a limited capability to log custom fields through the Response.AppendToLog method. The limitation, however, is that a new field is not created in the log files, but this data is appended to the URI Query field. To distinguish the two values, you can separate them with a character such as the pipe ("|"). Below is example ASP code to log additional proxy headers:
<%
sHeader= Request.ServerVariables("X-Forwarded-For")
If Len(sHeader) Then Response.AppendToLog "|" & sHeader
%>
Note that other common proxy headers are Forwarded, Client_IP, Remote_Addr, Remote_Host, Forwarded, VIA, HTTP_From, Remote_Host_Wp, Xonnection, Xroxy_Connection, and X_Locking.
Microsoft's LogParser Tool
Digging through logs requires that you have some common interface to perform queries across hundreds of individual log files. One method is to dump all the logs into an SQL database. Another solution is Microsoft's LogParser tool. This robust tool provides an SQL interface to a variety of log file formats and is fast enough for log file analysis of most web sites. I won't go into detail here about how to use LogParser, but the document included with the package is very helpful to get started. Because LogParser is a command-line tool, I have found it useful to either to copy the file to the C:\WINNT directory or to add the LogParser directory to your PATH variable.
You can download Microsoft's LogParser 2.0 here, but the IIS 6 Resource Kit includes LogParser 2.1, which has some new features. Although LogParser 2.1 runs fine on a Win2k system, you cannot install the IIS 6 resource kit on Win2k. However, you can manually extract the resource kit files using the command: iis60rkt.exe /V/a.
It is important to note that when doing any log file processing, be sure to work on copies of the logs to help preserve the integrity of the original files (see Maintaining Credible Logfiles). I also find it helpful to only copy those logs for the time period I want to analyze to reduce the size of the query results.
This article will demonstrate many of the forensic capabilities of LogParser. Keep in mind that I wrote each of these example queries for a typical configuration, therefore you may need to adjust them for your particular site. Not all queries listed here will be effective for you, depending on your site configuration and traffic level.
Finding the Intrusion
If you do not know anything about the intruder or the nature of the intrusion, you must first do some high-level queries to know where to start your hunt. Most attacks leave some kind of trail or have some side-effect on your server. The trick is finding them.
Trojan Files
Before we dig in to the actual log files, it may be useful to do a quick check of the newest files on the web site. If the intruder was able to create or modify files within the web content directories, he or she may have uploaded Trojan ASP scripts or executables. You might just get lucky and find these files. The following query lists the 20 newest files on the web site:
C:\>logparser -i:FS "SELECT TOP 20 Path, CreationTime from c:\inetpub\wwwroot\*.* ORDER BY CreationTime DESC" -rtp:-1
But suppose the attacker was careful and deleted all Trojan files when finished. In that case, the files will not be exist but there will be log entries showing successful requests for those files. To identify these log entries you must make a list of all files on your site that have resulted in 200 HTTP status codes. From your log files directory, execute the following query:
C:\WINNT\System32\LogFiles\W3SVC1>logparser "SELECT DISTINCT TO_LOWERCASE(cs-uri-stem) AS URL, Count(*) AS Hits FROM ex*.log WHERE sc-status=200 GROUP BY URL ORDER BY URL" -rtp:-1
Carefully review this list and make sure that each item listed is part of your web application. In particular, watch for files such as nc.exe, tini.exe, root.exe, cmd.exe, upload.asp, aspexec.asp, etc.
Script Abuse
If searching for new or modified files turns up nothing, it is time to check out your scripts and executables. Any script or executable that accepts user input is a potential attack vector. Before starting, you should identify which executable file extensions you use in your web content areas. The following query will give you a report of all file extensions that exist within your web content (adjust the path names as necessary):
C:\>logparser -i:fs "SELECT TO_LOWERCASE(SUBSTR(Name, LAST_INDEX_OF(Name,'.'), STRLEN(Name))) AS Extension, Count(*) as Files from c:\inetpub\wwwroot\*.*, c:\inetpub\scripts\*.* WHERE Attributes NOT LIKE 'D%' GROUP BY Extension ORDER BY Files DESC" -rtp:-1
According to this list, the site contains several file extensions that may be of concern to us: .asp and .dll. Therefore, all the example queries from this point on will specifically look for ASP and DLL files. You will likely need to adjust this depending on which executable extensions you use on your web site.
One way to detect script abuse is to see if any one script has an unusually high number of hits. Since web-based attacks often require some trial and error, you should expect to see noticeable statistical variances, unless of course your web site gets millions of hits a day. Nevertheless, it is sometimes useful to see if any single day produced unusually high traffic.
The following query will show the number of hits for each day for each ASP and DLL file. From your log files directory, type the following:
C:\WINNT\System32\LogFiles\W3SVC1>LogParser "SELECT TO_STRING(TO_TIMESTAMP(date, time), 'yyyy-MM-dd') AS Day, cs-uri-stem, COUNT(*) AS Total FROM ex*.log WHERE (sc-status<400 or sc-status>=500) AND (TO_LOWERCASE(cs-uri-stem) LIKE '%.asp%' OR TO_LOWERCASE(cs-uri-stem) LIKE '%.exe%') GROUP BY Day, cs-uri-stem ORDER BY cs-uri-stem, Day" -rtp:-1
In the sample results above the number of hits on 2004-04-07 is suspiciously high and should be investigated further.
Another good attack indicator is the number of errors per hour. The following script returns the dates and hours that had more than 25 error codes returned. This value will likely need adjusting depending on how much traffic your site receives:
C:\WINNT\System32\LogFiles\W3SVC1>logparser "SELECT date, QUANTIZE(time, 3600) AS hour, sc-status, Count(*) AS Errors FROM ex03*.log WHERE sc-status>=400 GROUP BY date, hour, sc-status HAVING Errors>25 ORDER BY Errors DESC" -rtp:-1
Further investigation of the dates listed above may show that the high number of 404 errors are CGI scans looking for vulnerable scripts on your site. The 404 errors themselves are not as much as a concern as are the 200 results during that same time that may indicate a successful attack. This query will return all valid requests from any IP address that also had a 404 error on 2003-06-22:
C:\WINNT\System32\LogFiles\W3SVC1>logparser "SELECT c-ip, cs-uri-stem, Count(*) as Hits FROM ex*.log WHERE TO_LOWERCASE(cs-uri-stem) NOT LIKE '%.gif' AND TO_LOWERCASE(cs-uri-stem) NOT LIKE '%.jpg%' AND c-ip IN (SELECT c-ip FROM ex030622.log WHERE sc-status=404) AND sc-status=200 GROUP BY c-ip, cs-uri-stem" -rtp:-1
Looking at these results, you can see two IP addresses that had an unusual number of hits on Products.asp. It could be that these were two different attackers or the same attacker who used two different proxies to conceal his or her IP address. One way to find out if they are likely the same person is to check the User-Agent header for the two different IP addresses:
C:\WINNT\System32\LogFiles\W3SVC1>logparser "SELECT DISTINCT c-ip, cs(User-Agent) FROM ex030622.log WHERE c-ip='198.54.202.2' or c-ip='62.135.71.223'" -rtp:-1
This proves that those two IP addresses are either the same user or two different users with the exact same OS, browser, service pack level, installed hotfixes, and .NET installation. It is not a perfect indicator but it is significant. To support this evidence, you could go through your logs and discover when each of the IP addresses first hit your web site. When a user visits a web site for the first time, the browser downloads the page and any graphics and stores it all in the browser's temporary cache. This is so that subsequent visits to the page will not require downloading all the graphics again. However, the browser does check to see if the graphics have been modified before using the cached versions. If the graphic has not been modified, the server will return a 304 HTTP status code. Therefore, if you create a query for a specific IP address with a status code of 200 for any particular graphic, that log entry will be the user's first visit, providing they have not cleared their cache. So if a user switches to a different proxy server, the file will still be cached and therefore there will never be a first visit from one of the IP addresses. If one of the two IP addresses mentioned above turns up not having a first visit, chances are that they first visited the site from the other IP address. If neither IP address shows a 200 result, then there are more IP addresses left to discover.
SQL Injection
If you read this paper (PDF) from NGSSoftware you will see that attacks such as SQL injection are based on sending faulty requests to a server and interpreting the error messages. Some of the indicators of this type of attack are:
Numerous sequential hits from the same IP address to the same URL;
High numbers of 500 HTTP status codes or other errors;
GET requests to ASP pages that normally only receive POST requests; and
Other clusters of anomalous web site activity.
It may also be useful to see an unusually high number of hits on a single page from a single IP address. The following query shows any IP address that hit the same page more than 50 times in a single day:
C:\WINNT\System32\LogFiles\W3SVC1>logparser "SELECT DISTINCT date, cs-uri-stem, c-ip, Count(*) AS Hits FROM ex*.log GROUP BY date, c-ip, cs-uri-stem HAVING Hits>50 ORDER BY Hits Desc" -rtp:-1
Looking at these results, it is immediately obvious that one IP address hit the same page 281 times one day and 91 times another day, which is obviously suspicious.
Another useful technique is to view exactly what ASP errors IIS encountered while serving requests. Most attempts at breaking into a web site will inevitably result in some kind of error. The following query will return a list of every ASP error recorded in the log files:
C:\WINNT\System32\LogFiles\W3SVC1>logparser "SELECT cs-uri-query, Count(*) AS Total FROM ex*.log WHERE sc-status>=500 GROUP BY cs-uri-query ORDER BY Total DESC " -rtp:-1
If you find any errors that are interesting, you could write another query to drill down to the specific error. In particular, you want to watch for ODBC and ADO errors, indicating a possible attempt at SQL injection.
Another way to identify errors is to look at the status codes returned by the server. If you want to see a detail of what status codes IIS returned for each page, try the following query:
C:\WINNT\System32\LogFiles\W3SVC1>logparser "SELECT cs-uri-stem, sc-status, Count(*) AS Total FROM ex*.log WHERE TO_LOWERCASE(cs-uri-stem) LIKE '%.asp%' or TO_LOWERCASE(cs-uri-stem) LIKE '%.exe%' GROUP BY cs-uri-stem, sc-status ORDER BY cs-uri-stem, sc-status" -rtp:-1
Also of interest are the Win32 Status codes, which may be attack indicators:
C:\WINNT\System32\LogFiles\W3SVC1>logparser "SELECT cs-uri-stem, WIN32_ERROR_DESCRIPTION(sc-win32-status) as Error, Count(*) AS Total FROM ex*.log WHERE sc-win32-status>0 and (TO_LOWERCASE(cs-uri-stem) LIKE '%.asp%' or TO_LOWERCASE(cs-uri-stem) LIKE '%.exe%') GROUP BY cs-uri-stem, Error ORDER BY cs-uri-stem, Error" -rtp:-1
cs-uri-stem Error Total
------------------------ ------------------------------------ -----
/Default.asp The RPC server is unavailable. 2
/Default.asp The remote procedure call failed 1
/asp/aspmail.asp The RPC server is unavailable. 12
/download/Default.asp The RPC server is unavailable. 3
...
Some ASP pages should only accept form input from previous pages. If, for example, you may have a page such as checkout1.asp that sends a POST request to checkout2.asp, then anything other than a POST request to checkout2.asp may be suspicious. This query will show what HTTP methods were sent to each page:
C:\WINNT\System32\LogFiles\W3SVC1>logparser "SELECT cs-uri-stem, cs-method, Count(*) AS Total FROM ex*.log WHERE (sc-status<400 or sc-status>=500) AND (TO_LOWERCASE(cs-uri-stem) LIKE '%.asp%' or TO_LOWERCASE(cs-uri-stem) LIKE '%.exe%') GROUP BY cs-uri-stem, cs-method ORDER BY cs-uri-stem, cs-method" -rtp:-1
cs-uri-stem cs-method Total
------------------------------------ --------- -----
/Default.asp GET 9136
/Default.asp HEAD 125
/asp/aspmail.asp GET 3
/asp/aspmail.asp POST 111
/awards/Default.asp GET 269
/compare/Default.asp GET 437
/compare/Default.asp HEAD 3
/download/Default.asp GET 5018
/download/Default.asp HEAD 436
/download/default.asp GET 727
/download/default.asp HEAD 1
/orders/Default.asp GET 1420
/orders/Default.asp POST 3
...
You may also want to write a query that checks the HTTP referer header to make sure the traffic is coming from where you expect it to be coming from.
Digging Deeper
At this point, you should begin to see patterns emerge. You should be able to narrow down the attack to specific dates and URL's. If you still have not found any apparent patterns, you may need to dig deeper. Sometimes an attack will involve sending a large amount of information back to the attacker. The following query will report some statistics for the number of bytes sent to the client
C:\WINNT\System32\LogFiles\W3SVC1>logparser "SELECT cs-uri-stem, Count(*) as Hits, AVG(sc-bytes) AS Avg, Max(sc-bytes) AS Max, Min(sc-bytes) AS Min, Sum(sc-bytes) AS Total FROM ex*.log WHERE TO_LOWERCASE(cs-uri-stem) LIKE '%.asp%' or TO_LOWERCASE(cs-uri-stem) LIKE '%.exe%' GROUP BY cs-uri-stem ORDER BY cs-uri-stem" -rtp:-1
And this one will report on bytes sent from the client:
C:\WINNT\System32\LogFiles\W3SVC1>logparser "SELECT cs-uri-stem, Count(*) as Hits, AVG(cs-bytes) AS Avg, Max(cs-bytes) AS Max, Min(cs-bytes) AS Min, Sum(cs-bytes) AS Total FROM ex*.log WHERE TO_LOWERCASE(cs-uri-stem) LIKE '%.asp%' or TO_LOWERCASE(cs-uri-stem) LIKE '%.exe%' GROUP BY cs-uri-stem ORDER BY cs-uri-stem" -rtp:-1
Another indicator may be how much time the server spent processing the request. It is not uncommon for exploits to take an unusually large amount of time or even timeout completely. The following query reports on time taken:
C:\WINNT\System32\LogFiles\W3SVC1>logparser "SELECT cs-uri-stem, Count(*) as Hits, AVG(time-taken) AS Avg, Max(time-taken) AS Max, Min(time-taken) AS Min, Sum(time-taken) AS Total FROM ex*.log WHERE TO_LOWERCASE(cs-uri-stem) LIKE '%.asp%' or TO_LOWERCASE(cs-uri-stem) LIKE '%.exe%' GROUP BY cs-uri-stem ORDER BY cs-uri-stem" -rtp:-1
If your site is mostly unauthenticated anonymous access, then any user login may be suspicious. To see what users have authenticated to the site, try the following query:
C:\WINNT\System32\LogFiles\W3SVC1>logparser "SELECT cs-username, Count(*) AS Hits from ex*.log WHERE cs-username IS NOT NULL GROUP BY cs-username ORDER BY Hits Desc" -rtp:-1
User-Agents
Sometimes it is possible to identify an attack script by looking at the HTTP User-Agent header sent by the client. You can get a list of non-standard User-Agent strings with this query:
C:\WINNT\System32\LogFiles\W3SVC1>logparser "SELECT DISTINCT cs(User-Agent) FROM ex*.log WHERE TO_LOWERCASE(cs(User-Agent)) NOT LIKE '%mozilla%' AND TO_LOWERCASE(cs(User-Agent)) NOT LIKE '%opera%' ORDER BY cs(User-Agent)" -rtp:-1
Closing In
Following these same patterns, you will eventually close in on the source of the intrusion or identify unknown intrusions. With each query, try to add more criteria and more detail to identify the specific log evidence to identify the attacker or type of attack. LogParser is a very powerful tool, but the real power comes when you learn how to use these and other queries to quickly bring information to your fingertips
IIS log files queries These examples assume the log format used is W3C Extended. If a different format is used, the field names may need to be changed.
SELECT EXTRACT_EXTENSION( cs-uri-stem ) AS Extension,
MUL(PROPSUM(sc-bytes),100.0) AS Bytes
INTO Pie.gif
FROM <1>
GROUP BY Extension
ORDER BY Bytes DESC
SELECT TOP 20 cs-method,
COUNT(*) AS Total,
MAX(time-taken) AS MaxTime,
AVG(time-taken) AS AvgTime,
AVG(sc-bytes) AS AvgBytesSent
FROM ex*.log
GROUP BY cs-method
ORDER BY Total DESC
SELECT TOP 20 cs-uri-stem,
COUNT(*) AS Total,
MAX(time-taken) AS MaxTime,
AVG(time-taken) AS AvgTime,
AVG(sc-bytes) AS AvgBytesSent
FROM ex*.log
GROUP BY cs-uri-stem
ORDER BY Total DESC
SELECT STRCAT(TO_STRING(sc-status), STRCAT('.', TO_STRING(sc-substatus))) AS Status,
COUNT(*) AS Total
FROM ex*.log
GROUP BY Status
ORDER BY Total DESC
SELECT EXTRACT_TOKEN(FullUri, 0, '|') AS Uri,
EXTRACT_TOKEN(cs-uri-query, -1, '|') AS ErrorMsg,
EXTRACT_TOKEN(cs-uri-query, 1, '|') AS LineNo,
COUNT(*) AS Total
USING STRCAT( cs-uri-stem,
REPLACE_IF_NOT_NULL(cs-uri-query, STRCAT('?', cs-uri-query))
) AS FullUri
FROM ex*.log
WHERE (sc-status = 500) AND (cs-uri-stem LIKE '%.asp')
GROUP BY Uri, ErrorMsg, LineNo
ORDER BY Total DESC
SELECT STRCAT( cs-uri-stem,
REPLACE_IF_NOT_NULL(cs-uri-query, STRCAT('?',cs-uri-query))
) AS Request,
STRCAT( TO_STRING(sc-status),
STRCAT( '.',
COALESCE(TO_STRING(sc-substatus), '?' )
)
) AS Status,
COUNT(*) AS Total
FROM ex*.log
WHERE (sc-status >= 400)
GROUP BY Request, Status
ORDER BY Total DESC
SELECT cs-username,
sc-status,
COUNT(*) AS Total
FROM ex*.log
WHERE cs-username IS NOT NULL AND sc-status BETWEEN 401 AND 403
GROUP BY cs-username,sc-status
ORDER BY Total DESC
SELECT STRCAT( EXTRACT_TOKEN( Strings,
1,
'|'),
STRCAT( '\\',
EXTRACT_TOKEN( Strings,
0,
'|'
)
)
) AS User,
COUNT(*) AS Total
FROM Security
WHERE EventType = 16 AND EventCategory = 2
GROUP BY User
ORDER BY Total DESC
SELECT
COUNT(EventID) AS TotalLogonFailures,
TO_LOWERCASE(EXTRACT_TOKEN(Strings,0,'|')) AS User,
TO_LOWERCASE(EXTRACT_TOKEN(Strings,1,'|')) AS Domain,
TO_LOWERCASE(EXTRACT_TOKEN(Strings,5,'|')) AS WorkStation,
CASE TO_INT(EXTRACT_TOKEN(Strings,2,'|'))
WHEN 2 THEN 'Interactive - Intended for users who will be interactively using the machine, such as a user being logged on by a terminal server, remote shell, or similar process.'
WHEN 3 THEN 'Network - Intended for high performance servers to authenticate clear text passwords. LogonUser does not cache credentials for this logon type.'
WHEN 4 THEN 'Batch - Intended for batch servers, where processes may be executing on behalf of a user without their direct intervention; or for higher performance servers that process many clear-text authentication attempts at a time, such as mail or web servers. LogonUser does not cache credentials for this logon type.'
WHEN 5 THEN 'Service - Indicates a service-type logon. The account provided must have the service privilege enabled.'
WHEN 6 THEN 'Proxy - Indicates a proxy-type logon.'
WHEN 7 THEN 'Unlock - This logon type is intended for GINA DLLs logging on users who will be interactively using the machine. This logon type allows a unique audit record to be generated that shows when the workstation was unlocked.'
WHEN 8 THEN 'NetworkCleartext - Windows 2000; Windows XP and Windows Server 2003 family: Preserves the name and password in the authentication packages, allowing the server to make connections to other network servers while impersonating the client. This allows a server to accept clear text credentials from a client, call LogonUser, verify that the user can access the system across the network, and still communicate with other servers.'
WHEN 9 THEN 'NewCredentials - Windows 2000; Windows XP and Windows Server 2003 family: Allows the caller to clone its current token and specify new credentials for outbound connections. The new logon session has the same local identity, but uses different credentials for other network connections.'
WHEN 10 THEN 'RemoteInteractive - Terminal Server session that is both remote and interactive.'
WHEN 11 THEN 'CachedInteractive - Attempt cached credentials without accessing the network.'
WHEN 12 THEN 'CachedRemoteInteractive - Same as RemoteInteractive. This is used for internal auditing.'
WHEN 13 THEN 'CachedUnlock - Workstation logon'
ELSE EXTRACT_TOKEN(Strings,2,'|')
END AS Type
INTO DATAGRID
FROM \\%machine%\security
WHERE EventID IN (529)
GROUP BY User,Domain,WorkStation,Type
ORDER BY TotalLogonFailures DESC
SELECT STRCAT( EXTRACT_TOKEN( Strings,
1,
'|'),
STRCAT( '\\',
EXTRACT_TOKEN( Strings,
0,
'|'
)
)
) AS User,
COUNT(*) AS Total
FROM Security
WHERE EventType = 8 AND EventCategory = 2
GROUP BY User
ORDER BY Total DESC
SELECT SourceName,
EventID,
MUL(PROPCOUNT(*) ON (SourceName), 100.0) AS Percent
FROM System
GROUP BY SourceName, EventID
ORDER BY SourceName, Percent DESC
프로그램 이름 : AnySend 2008 (애니센드 2008)
최신버전 : 1.0.6.7
제품가격 : 25,000원
한정판매 : 100 카피만 한정 판매 (기간 관계없이 선착순 100명에게만 판매)
판매방식 : 입금 → 확인 → 구매자에게 프로그램 발송(아이디/시리얼포함)
구매혜택 : E-mail을 통한 기술지원, 최신버전 무료 발송, 차후 온라인 업데이트 지원
제품특징 : 메일 서버 불필요, 실행파일(EXE파일) 1개만으로 메일 발송 가능
사용환경 : Windows XP SP2/SP3, Vista
인터넷 공유기 사용시 사용 불가!
01. 익명 메일이란
사용하는 실제 메일 아이디를 사용하지 않고 자신이 원하는 ID로 바꿔서
메일을 보내는 것을 말한다.
대형 포털 사이트인 다음이나 네이버등에서 닉네임을 바꿔서 보내는것은 전혀 의미가 없다.
받는 사람에게는 여전히 동일한 아이디로 나오기 때문에 익명이라 할 수가 없으며 무엇보다
실명 가입자만이 사용할 수 있는 이러한 대형 포털사이트를 사용하는 것 자체가 익명이라
할 수가 없는 것이다.
02. 익명 메일이 필요한 이유
국내의 포털사이트 같은 경우 기술적/제도적인 보호장치가 뒷받침되어 안심하고
사용할 수는 있지만 여전히 잘 모르는 누군가에게 나의 메일 주소를 공개한다는 것은
꺼려지는 일이며 별로 원치 않는 일이다.
또한 지금은 누구나 메일 계정을 여러 개 이상 가지고 있으며 어느 누구라도 마음만 먹으면
메일 주소 하나만으로도 특정 개인에 대해서 얻을 수 있는 정보가 온라인에는 넘쳐난다.
(블로그, 홈페이지, 미니홈피등...검색 엔진을 잘 활용하면 더 놀라운 정보도 알아낸다)
이렇게 우리는 원하지 않아도 자신의 개인 정보를 노출할 수 밖에 없는 세상에 살고 있는 것이다.
자신의 중요 정보를 알리지 않고 메일을 보낼 수 있으면 얼마나 좋겠는가.
03. 익명 메일의 사용 예
- 직장 상사에게 도저히 말로 할 수 없는 건의를 하고 싶을 때
- 특정 비리 또는 사건을 회사의 오너 또는 관계 기관에 고발하고 싶을 때
- 짝사랑으로 마음이 아프지만 말로는 고백할 수 없을 때...-_-; 이유야 어찌됐든 암튼 가능하다.
- 타인에게 자신의 메일 주소를 알리고 싶지 않는 모든 경우
- 사람같지도 않는 사람에게 욕한마디 해주고 싶을 경우
04. AnySend 2008 소개
AnySend 2008은 위에 설명한 조건을 모두 만족하는 프로그램입니다.
프로그램이기 때문에 회원 가입이나 로그인 등의 절차가 필요없으며, 프로그램의 설치만
끝나면 즉시 사용할 수 있습니다.
[주요 기능 소개]
- 발신인 설정 기능 (포털로 말하면 닉네임 또는 별칭. 자신이 원하는대로 설정하는 기능)
- 발신자 아이디 설정 기능 (자신이 원하는 어떠한 아이디로도 설정 가능)
- 파일 첨부 기능 (오직 1개의 파일만 첨부 가능하며 압축해서 전송할 경우 문제없음)
- 주소록 기능이 포함되어 다수의 사람들에게 일괄적인 메일 전송이 가능 (최대 5000명)
- 발신 건수 설정으로 메일 전송이 가능 (개별 전송시에만 가능하며 최대 5000건)
- 보안 메일 전송 기능 (메일 본문을 암호화해서 상대방에게 전송함)
- 보안 메일이 필요한 이유
- 우리가 편지함에서 메일을 삭제한다는 것은 실제로 삭제되는 것이 아니다
(관련 법규에 의거 포털사이트 등에서는 일정 기간 보관하도록 되어 있다)
- 누군가가 E-mail을 열어보지는 않을까 가슴을 졸인적이 있다
(업무상 기밀, 중요한 개인 프라이버시 등 보호해야 할 요소는 너무나 많다)
[AnySend 2008로 메일 전송이 가능한 사이트]
- 네이트닷컴 NATE.COM
- 네이버닷컴 NAVER.COM
- 파란닷컴 PARAN.COM
- 구글 G메일 GMAIL.COM
- MS 핫메일 HOTMAIL.COM
- 그 외 모든 메일 (초.중.고.대학교/기업/중소형 웹메일 등)
[AnySend2008로 메일 전송이 불가능한 사이트]
- 한메일(다음) HANMAIL.NET
05. 프로그램의 설치
06. 정품인증 받기
애니센드 2008은 상용 프로그램이기 때문에 프로그램의 설치 후 정품 인증 절차를 거쳐야 합니다.
프로그램을 구매하면 설치 프로그램과 함께 아이디와 시리얼 넘버를 발급해서 보내드립니다.
설치 후 발급받은 아이디와 시리얼 넘버를 입력하고 '인증요청' 버튼을 누릅니다.
인증요청이 성공했을 경우의 메시지이며 1분~10분 후에 프로그램을 재시작하면
인증창은 출력되지 않고 정상적으로 사용할 수 있습니다.
만약 인증이 실패할 경우 화면의 지시에 따르면 됩니다.
07. 메일보내기
애니센드 2008을 사용해서 간단하게 메일을 보내보겠습니다.
다음과 같이 보내는사람, 보내는사람E-mail, 받는사람 E-mail주소, 제목, 본문을 입력하고 메일전송 버튼을 누르면 됩니다.
위 그림은 메일 전송의 결과 화면입니다.
이것은 옵션으로 환경설정에서 '전송 완료시 결과 리포트 보기' 옵션을 켜야만 나옵니다.
그럼 메일이 정확히 도착했는지 확인해보도록 하겠습니다.
위 그림과 같이 정확하게 도착했음을 확인할 수 있습니다.
08. 보안메일 기능
AnySend 2008의 보안메일 기능을 사용해서 메일을 보내보도록 하겠습니다
먼저 메일 메시지를 작성합니다.
위와 같이 메일의 내용을 모두 적었으면 프로그램의 상단에 있는 보안메일 버튼을 누릅니다.
보안메일 버튼을 누르면 위 그림과 같이 보안메일 윈도우가 나타납니다.
메일을 보내는 것이기 때문에 메시지 암호화를 선택한 다음 비밀번호를 입력하고 Enc/Dec 버튼을 누릅니다.
Enc/Dec 버튼을 누르면 위와 같이 메시지가 암호화된 것을 확인할 수 있습니다.
메일이 암호화되면 메일전송을 눌러서 메일을 보냅니다.
그럼 암호화된 메일을 확인해보고 이를 읽을 수 있는 방법을 알아보겠습니다.
위 그림과 같이 메일은 정확히 도착했으며 메시지의 본문은 암호화되어 있고
이것을 모르는 사용자를 위하여 암호화되었음을 알려주는 메시지가 자동으로 포함되어
전송됩니다.
이제 암호화된 부분을 읽기 위해서는 받은 메일에서 암호화된 부분을 복사하고
AnySend 2008을 실행해서 다음 그림과 같이 메시지 입력창에 붙여넣기 합니다.
그리고 보안메일 버튼을 눌러서 '메시지 복호화'을 선택하고 비밀번호를 누른 다음에 Enc/Dec 버튼을 누릅니다.
그럼 위와 같이 실제 원본 메시지로 정확하게 복호화된 것을 확인할 수 있습니다.
AnySend 2008은 메시지 암호화/복호화 기능 모두를 가지고 있기 때문에 사용자는
별도의 메일 뷰어가 필요가 없습니다만 다른 사용자에게 암호화된 메일을 보낼 경우에는
어떻게 해야 할까요? 받는 사람도 AnySend 2008을 구매해야 할까요?
그렇지 않습니다. 아래 그림과 같이 AnySend 2008로 암호화된 메일을 확인할 수 있도록
애니센드 보안메일 뷰어(AnySend Secure Mail Viewer) 프로그램을 배포하고 있으며
누구나 무료로 다운로드 및 사용이 가능합니다.
애니센드 보안메일 뷰어도 AnySend 2008과 똑같이 암호화된 메일 본문을 붙여넣고
비밀번호를 입력한 뒤 메시지보기를 클릭하면 됩니다.
위의 그림과 같이 AnySend 2008로 전송된 보안 메일을 쉽고 빠르게 확인할 수 있습니다.
애니센드 보안 메일 뷰어에는 암호화 기능이 없으며 오직 암호화된 메일을 볼 수 있는
기능만 포함되어 있습니다.
09. 환경설정
환경설정은 별도의 설명이 필요없을 정도로 쉽게 구성되어 있습니다.
'접속/전송 실패시 전체 전송 중단' 옵션을 설정한 경우 실패 회수를 설정해야 합니다.
보내는 메일이 100명이고 실패 회수를 10건으로 설정하게 되면 100개의 메시지를 보내다가
접속실패나 전송실패의 개수가 합계가 10건이 될 경우 남아있는 메일이 몇 건인지와 관계없이
남아 있는 메일 전송을 취소하게 됩니다.
다른 옵션은 특별히 설명할 필요가 없이 간단합니다.
10. 주소록 기능
애니센드 2008에서는 주소록 관리 기능을 제공합니다.
따라서 메일 주소에서 원하는 사람만 선택해서 메일을 보낼 수 있습니다.
버튼 설명 : 총 5개의 버튼이 있는데 가장 좌측의 순서부터
(추가/수정/선택삭제/전체삭제/선택한 사용자를 받는사람에 추가) 의 기능을
가지고 있습니다. 주소록은 총 5000명의 주소를 관리할 수 있습니다.
입력된 주소록은 암호화되어 안전하게 저장됩니다.
11. 주의사항
이 프로그램을 악용하여 타인에게 폭탄메일, 명예훼손, 공갈 및 협박, 대량 불법스팸 발송 등의
행위를 통해서 정신적/물질적 손해를 입힌 경우 책임은 전적으로 발송한 사람에게 있으며
관계기관 또는 수사기관의 요청이 있을 경우 제작자는 구매자의 정보을 제공할 것입니다.
또한 본 프로그램의 무단 배포, 보호장치 해제, 인터넷을 사용하여 불법 공유할 경우
프로그램의 사용이 중지되며 저작권법 및 프로그램 보호법 위반으로 처벌받을 수 있습니다.
12. 소스판매
이 프로그램은 Visual C++ 2003로 작성되었으며 풀 소스(Full Source) 판매도 가능합니다.
외부 의존적인 별도의 라이브러리없이 VC++ .NET 2003 버전으로 즉시 컴파일 & 빌드됩니다.
[프로젝트 구성]
Header 파일 (*.h ) : 24개
CPP 파일 (*.cpp) : 24개
리소스 파일 (*.bmp, *.ico, *.wav, 기타) : 총 34개
설치 스크립트 : 1개
프로젝트 기술서 : 1개 (엑셀파일, 2007버전)
보호장치 기술서 : 1개 (엑셀파일, 2007버전)
풀 소스 구입시 제작자는 AnySend 2008의 개발 및 판매를 중지하며 저작권 일체를 포기합니다.
풀 소스 구입 가격 : 30,000,000원
13. 업그레이드 방법
기존 구버전의 구매자 분들께는 2008.07.17.목요일에 일괄적으로 최신버전을 발송해 드립니다.
14. 프로그램 문의
프로그램에 대한 문의는 블로그에 댓글 혹은 비밀 댓글을 달아주시거나
구입에 대한 문의는 메일로 보내주시기 바랍니다. (bitinitialize@gmail.com)
비밀 댓글을 남길 경우 답변은 비밀로 남길 수 없습니다.
또한 복사가 가능하다는 소프트웨어의 고유 특성상 환불은 불가능합니다.
15. 자주묻는 질문
제 메일로 자주오는 질문을 정리한 것입니다.
구매 의향이 있으신 분들은 한번 읽어보시고 결정하세요.
Q : G메일로 첨부 파일이 발송되지 않아요!
A : G메일 계정으로 첨부 파일을 보내는데 실패할 경우 RAR 방식으로 압축해보세요. 잘됩니다.
Q : 핫메일(hotmail)로 메일을 보냈는데 성공했다고 나오는데 메일이 오질 않아요!
A : 프로그램의 문제는 아닙니다. 겪어봐서 상황은 알고 있습니다만
핫메일 내부의 문제인 것 같습니다. 오늘 2008.07.16일 기준 메일발송 됩니다.
Q : HTML로 메일을 보내고 싶습니다. 가능할까요?
A : 가능합니다. HTML로 메일을 작성하시고 편집창에 붙여넣고 보내면 됩니다.
단 이 경우 해당 메일서버가 HTML을 자동으로 인식할 수 있어야 합니다.
예를 들어서 네이버로 HTML로 작성된 메일을 보낼 경우 정확히 전송/수신 됩니다.
Q : 네이버로 메일을 보냈는데 메일이 안와요!
A : 네이버 메일은 100% 전송입니다. 가끔 수신 서버에 따라서 늦게 도착하는 경우가 있습니다.
Q : 한메일로 메일이 안가요!
A : 소개에도 나와있듯이 한메일은 메일 전송/수신의 정책이 너무나 강력하여
온라인 우표제 등록을 하거나 해킹을 하지 않는 이상 메일 전송이 불가능합니다.
한메일은 현재 버전에서는 지원되지 않으니 다량의 메일을 전송하지 마세요.
스팸IP로 등록되어 불이익을 받을 수 있습니다.
Q : 프로그램 소개에 없는 다른 메일 주소는 전송이 가능한지 확인할 수 있는 방법은 없나요?
A : 원하시는 메일 주소를 블로그에 댓글로 남겨주세요. 제가 가입 후 테스트하고 결과를
알려드리겠습니다.
Q : 메일 서버가 없어도 메일이 전송 가능하나요?
A : 소개에도 나와있듯이 메일서버는 없어도 됩니다.
Q : 프로그램의 크기는 얼마나 되나요?
A : 0.9MB(메가바이트)로 작은 용량의 사이즈입니다.
Q : 상대방이 제가 익명 메일로 보냈다는 사실을 알 수 있나요?
A : 당연히 모릅니다. AAAAA@AAAA.COM 과 같이 황당한 메일 주소로 보내지만 않는다면
의심하지도 않겠지요.
Q : 프로그램이 너무 비싸요ㅠ
A : 10년만 기다려보세요. 누군가 프리웨어로 만들지도 모르겠네요.
참고로 10년전에도 이만큼 쓸만한건 별로 없었습니다. 폭탄 메일로 일컬어지는
몇 몇의 프로그램이 있긴 했었지만 그러한 프로그램들은 백신조차도 악성으로 진단하는것이고
애초 목적이 나쁜 목적으로 제작된 것입니다.
E-mail 기술지원, 새버전의 무료 업그레이드까지 제공하는데 비싸다고 하시는건....=_=
Q : 익명 메일을 보냈는데 추적이 가능한가요?
A : 답변은 0%, 100% 두가지입니다.
관련 법규가 지정하고 있는대로 불법 행위만 하지 않는다면 어느 누가 추적을 하겠습니까?
주의사항에도 나와 있듯이 불법 행위를 저지를 경우 추적과 체포는 기정 사실입니다.
반면 단지 ID만 바꿔서 익명으로 메일 하나 보냈다고 세상 어느경찰이 추적을 하겠습니까?
IP 추적이라는 것은 '고소'라는 선행 절차가 있어야 하며 수사기관에서 통신서비스제공자에게
요청을 해야만 알 수 있는 것입니다. 개인이 개인을 추적한다는 것은 불가능하며 대다수가
잘못 알고 있는 경우가 많습니다. WHOIS라는 서비스가 있습니다.
인터넷이 생길 당시부터 존재하던 서비스일 뿐인데 이것을 잘못 알고 IP추적이라고 일컫는
사람들이 있는데 실제로는 해당 IP가 어느 국가 어느 통신 사업자에게 할당되었는지만
알 수 있을 뿐입니다. 고정 IP라 할지라도 소속만 알 수 있을 뿐이지 그 이상은 모릅니다.
Q : 보안메일을 사용할 경우 얼마나 안전합니까?
A : 뛰어난 프로그래머 내지는 뛰어난 해커가 아니라면 포기해야 할 정도로 안전합니다.
물론 비밀번호를 1111 정도로 간단하게 한다면야....컴맹이나 초보 프로그래머도 풀겠지요.
올바른 비밀번호는 단어를 사용하는 것이 아니고 숫자와 문자를 조합하는 것입니다.
Exam : @!4ehg6*83fi4#1gbw6^fd8 (해커에게 풀어보라 하십시오. 얼마나 걸릴까요?)
