start writing
This commit is contained in:
parent
0381009448
commit
e3c313e93c
5 changed files with 3201 additions and 0 deletions
252
procver/ACNS/biblio.bib
Normal file
252
procver/ACNS/biblio.bib
Normal file
|
|
@ -0,0 +1,252 @@
|
||||||
|
|
||||||
|
@misc{smith_evasion_2022,
|
||||||
|
title = {Evasion {Techniques} — {Hiding} your process from `ps`},
|
||||||
|
url = {https://keiran.scot/2022/10/10/Evasion-Techniques-Hiding-your-process-from-ps/},
|
||||||
|
abstract = {Everything in Linux is a file, that even goes for your process information. This lived inside the /proc directory on your filesystem. Today we will use and abuse this knowledge to hide a target process from the ps command in Linux, and in essence other Unix based systems. But first…
|
||||||
|
How does the ps command work? As mentioned previously everything in Linux is a file, including the process tree in /proc.},
|
||||||
|
language = {en-us},
|
||||||
|
urldate = {2024-11-08},
|
||||||
|
author = {Smith, Keiran},
|
||||||
|
month = oct,
|
||||||
|
year = {2022},
|
||||||
|
note = {Section: posts},
|
||||||
|
annote = {Try that for both hiding and masquerading a process.
|
||||||
|
},
|
||||||
|
file = {Snapshot:/home/grizzly/Zotero/storage/EUYRZ2P7/Evasion-Techniques-Hiding-your-process-from-ps.html:text/html},
|
||||||
|
}
|
||||||
|
|
||||||
|
@article{almshari_detection_2020,
|
||||||
|
title = {Detection of {Potentially} {Compromised} {Computer} {Nodes} and {Clusters} {Connected} on a {Smart} {Grid}, {Using} {Power} {Consumption} {Data}},
|
||||||
|
volume = {20},
|
||||||
|
copyright = {http://creativecommons.org/licenses/by/3.0/},
|
||||||
|
issn = {1424-8220},
|
||||||
|
url = {https://www.mdpi.com/1424-8220/20/18/5075},
|
||||||
|
doi = {10.3390/s20185075},
|
||||||
|
abstract = {Monitoring what application or type of applications running on a computer or a cluster without violating the privacy of the users can be challenging, especially when we may not have operator access to these devices, or specialized software. Smart grids and Internet of things (IoT) devices can provide power consumption data of connected individual devices or groups. This research will attempt to provide insides on what applications are running based on the power consumption of the machines and clusters. It is therefore assumed that there is a correlation between electric power and what software application is running. Additionally, it is believed that it is possible to create power consumption profiles for various software applications and even normal and abnormal behavior (e.g., a virus). In order to achieve this, an experiment was organized for the purpose of collecting 48 h of continuous real power consumption data from two PCs that were part of a university computer lab. That included collecting data with a one-second sample period, during class as well as idle time from each machine and their cluster. During the second half of the recording period, one of the machines was infected with a custom-made virus, allowing comparison between power consumption data before and after infection. The data were analyzed using different approaches: descriptive analysis, F-Test of two samples of variance, two-way analysis of variance (ANOVA) and autoregressive integrated moving average (ARIMA). The results show that it is possible to detect what type of application is running and if an individual machine or its cluster are infected. Additionally, we can conclude if the lab is used or not, making this research an ideal management tool for administrators.},
|
||||||
|
language = {en},
|
||||||
|
number = {18},
|
||||||
|
urldate = {2024-11-07},
|
||||||
|
journal = {Sensors},
|
||||||
|
author = {Almshari, Mohammed and Tsaramirsis, Georgios and Khadidos, Adil Omar and Buhari, Seyed Mohammed and Khan, Fazal Qudus and Khadidos, Alaa Omar},
|
||||||
|
month = jan,
|
||||||
|
year = {2020},
|
||||||
|
note = {Number: 18
|
||||||
|
Publisher: Multidisciplinary Digital Publishing Institute},
|
||||||
|
keywords = {autoregressive integrated moving average (ARIMA), descriptive analysis, F-Test of two samples of variance, IoT, machine learning, malware detection, power consumption, privacy, security, smart grid, two-way analysis of variance (ANOVA)},
|
||||||
|
pages = {5075},
|
||||||
|
annote = {The goal here is to detect what application are running on a machine based on the power consumption. The application is very relevant as it concerns computers in a university and not specialized machines.
|
||||||
|
},
|
||||||
|
file = {Full Text PDF:/home/grizzly/Zotero/storage/FPWN8QSX/Almshari et al. - 2020 - Detection of Potentially Compromised Computer Nodes and Clusters Connected on a Smart Grid, Using Po.pdf:application/pdf},
|
||||||
|
}
|
||||||
|
|
||||||
|
@inproceedings{james_detection_2017,
|
||||||
|
title = {Detection of anomalous behavior of smartphones using signal processing and machine learning techniques},
|
||||||
|
url = {https://ieeexplore.ieee.org/document/8292418},
|
||||||
|
doi = {10.1109/PIMRC.2017.8292418},
|
||||||
|
abstract = {Different applications in smartphones result in different power consumption patterns. The fact that every application has been coded to perform different tasks leads to the claim that every action onboard (whether software or hardware) will consequently have a trace in the power consumption of the smartphone. Even though the power consumed by the application might not be the same every time it is used, there still remains a similarity in the power consumption pattern. An anomalous behavior on the smartphone would result in a reduction in the similarity of the power consumption pattern. This change in similarity can be used to detect the presence of anomalous behavior of smartphones. We have proposed two approaches to detecting anomalous behavior on smartphones based on the power consumption pattern. The first approach is based on signal processing and the second approach explores the area of statistical learning in detecting malware. The two approaches have been analysed, evaluated, and compared. It has been observed that the signal processing method of detection performed better for anomalous behavior of lower intensity and the statistical learning method performed better for higher intensity anomalous behavior. It was also observed that both the methods are complementary.},
|
||||||
|
urldate = {2024-11-07},
|
||||||
|
booktitle = {2017 {IEEE} 28th {Annual} {International} {Symposium} on {Personal}, {Indoor}, and {Mobile} {Radio} {Communications} ({PIMRC})},
|
||||||
|
author = {James, R. Soundar Raja and Albasir, A. and Naik, K. and Dabbagh, M. Y. and Dash, P. and Zamani, M. and Goel, N.},
|
||||||
|
month = oct,
|
||||||
|
year = {2017},
|
||||||
|
note = {ISSN: 2166-9589},
|
||||||
|
keywords = {Malware, Power demand, Power measurement, Signal processing, Smart phones, Statistical learning},
|
||||||
|
pages = {1--7},
|
||||||
|
annote = {Power pattern detection and anomalous activity detection, but on smartphone.
|
||||||
|
},
|
||||||
|
file = {Full Text PDF:/home/grizzly/Zotero/storage/JQL8YJ2D/James et al. - 2017 - Detection of anomalous behavior of smartphones using signal processing and machine learning techniqu.pdf:application/pdf;IEEE Xplore Abstract Record:/home/grizzly/Zotero/storage/XQE3UMIP/8292418.html:text/html},
|
||||||
|
}
|
||||||
|
|
||||||
|
@inproceedings{bridges_towards_2018,
|
||||||
|
title = {Towards {Malware} {Detection} via {CPU} {Power} {Consumption}: {Data} {Collection} {Design} and {Analytics}},
|
||||||
|
shorttitle = {Towards {Malware} {Detection} via {CPU} {Power} {Consumption}},
|
||||||
|
url = {https://ieeexplore.ieee.org/document/8456118},
|
||||||
|
doi = {10.1109/TrustCom/BigDataSE.2018.00250},
|
||||||
|
abstract = {This paper presents an experimental design and algorithm for power-based malware detection on general-purpose computers. Our design allows programmatic collection of CPU power profiles for a fixed set of non-malicious benchmarks, first running in an uninfected state and then in an infected state with malware running along with non-malicious software. To characterize power consumption profiles, we use both simple statistical and novel, sophisticated features. We propose an unsupervised, one-class anomaly detection ensemble and compare its perfor-mance with several supervised, kernel-based SVM classifiers (trained on clean and infected profiles) in detecting previously unseen malware. The anomaly detection system exhibits perfect detection when using all features across all benchmarks, with smaller false detection rate than the supervised classifiers. This paper provides a proof of concept that power-based malware detection is feasible for general-purpose computers and presents several future research steps toward that goal.},
|
||||||
|
urldate = {2024-11-07},
|
||||||
|
booktitle = {2018 17th {IEEE} {International} {Conference} {On} {Trust}, {Security} {And} {Privacy} {In} {Computing} {And} {Communications}/ 12th {IEEE} {International} {Conference} {On} {Big} {Data} {Science} {And} {Engineering} ({TrustCom}/{BigDataSE})},
|
||||||
|
author = {Bridges, Robert and Hernández Jiménez, Jarilyn and Nichols, Jeffrey and Goseva-Popstojanova, Katerina and Prowell, Stacy},
|
||||||
|
month = aug,
|
||||||
|
year = {2018},
|
||||||
|
note = {ISSN: 2324-9013},
|
||||||
|
keywords = {Malware, Power demand, anomaly detection, Anomaly detection, Benchmark testing, Computers, Detectors, intrusion detection, malware, power monitoring, rootkit, side channel analysis},
|
||||||
|
pages = {1680--1684},
|
||||||
|
annote = {This paper focuses on collecting a power dataset for infected and clean machine and then training a model to classify them. This is a good step toward verification of loca lressources (the label infected/clean is kind of a local ressource) but the method and goal are very different: malware vs hidden processes and SVM classification vs NN regression.
|
||||||
|
},
|
||||||
|
file = {Full Text PDF:/home/grizzly/Zotero/storage/RYB2CQ8U/Bridges et al. - 2018 - Towards Malware Detection via CPU Power Consumption Data Collection Design and Analytics.pdf:application/pdf;IEEE Xplore Abstract Record:/home/grizzly/Zotero/storage/PCBDDMKS/8456118.html:text/html},
|
||||||
|
}
|
||||||
|
|
||||||
|
@inproceedings{sukhija_towards_2022,
|
||||||
|
address = {New York, NY, USA},
|
||||||
|
series = {{MEDES} '22},
|
||||||
|
title = {Towards {Anomaly} {Detection} for {Monitoring} {Power} {Consumption} in {HPC} {Facilities}},
|
||||||
|
isbn = {978-1-4503-9219-8},
|
||||||
|
url = {https://doi.org/10.1145/3508397.3564826},
|
||||||
|
doi = {10.1145/3508397.3564826},
|
||||||
|
abstract = {Given the increasing complexity and the heterogeneity of today's computing system infrastructure, power efficiency and fault tolerance remain the top challenges of an High Performance Computing (HPC) facility operation. Recently, many research efforts are focusing on monitoring solutions for collecting, correlating, and analyzing computing infrastructures health events and metrics data to not only identify the normal events but also the anomalous, thus aiding to reduce downtime and power consumption in the face of a computational center's and users' critical needs. In this preliminary work, we present an anomaly detection methodology integrated with the Operations Monitoring and Notification Infrastructure (OMNI) data warehouse at Lawrence Berkeley National Laboratory's (LBNL) National Energy Scientific Computing Center (NERSC) that has implemented anomaly detection algorithms for identifying abnormal power patterns. We evaluated our methodology using five million unlabeled power datasets from the Cori computation system at NERSC and reported on the accuracy of the anomaly detection algorithms in detecting different anomalous behavior pertaining to the amount of power consumed. The methodology is employed to aid in monitoring and automating power alerting to achieve power efficiency and reliability in future systems to be deployed at NERSC or other HPC facilities.},
|
||||||
|
urldate = {2024-11-07},
|
||||||
|
booktitle = {Proceedings of the 14th {International} {Conference} on {Management} of {Digital} {EcoSystems}},
|
||||||
|
publisher = {Association for Computing Machinery},
|
||||||
|
author = {Sukhija, Nitin and Bautista, Elizabeth and Butz, Drake and Whitney, Cary},
|
||||||
|
month = dec,
|
||||||
|
year = {2022},
|
||||||
|
pages = {1--8},
|
||||||
|
annote = {This article does not correlate with the logs at all. The detection of anomalous events is done purely with analysis of the power only using an unsupervised model trained on the power only.
|
||||||
|
},
|
||||||
|
file = {PDF:/home/grizzly/Zotero/storage/LW4J6TQN/Sukhija et al. - 2022 - Towards Anomaly Detection for Monitoring Power Consumption in HPC Facilities.pdf:application/pdf},
|
||||||
|
}
|
||||||
|
|
||||||
|
@inproceedings{takasaki_anomalous_2021,
|
||||||
|
title = {An {Anomalous} {Behavior} {Detection} {Method} {Based} on {Power} {Analysis} {Utilizing} {Steady} {State} {Power} {Waveform} {Predicted} by {LSTM}},
|
||||||
|
url = {https://ieeexplore.ieee.org/document/9486706},
|
||||||
|
doi = {10.1109/IOLTS52814.2021.9486706},
|
||||||
|
abstract = {Hardware security issues have emerged in recent years as Internet of Things (IoT) devices have rapidly spread. Power analysis is one of the methods to detect anomalous operations, but it is hard to apply it to IoT devices where an operating system and various software programs are running and hence its power waveforms become more complex. In this paper, we propose an anomalous behavior detection method utilizing application-specific power behaviors extracted by steady-state power waveform, which is generated by LSTM (long short-term memory). The proposed method is based on extracting application-specific power behaviors by predicting steady-state power waveforms. At that time, by using LSTM, we can effectively predict steady-state power waveforms, even if they include one or more cycled waveforms and/or they are composed of many complex waveforms. In the experiment, we implement three normal application programs and one anomalous application program on a single board computer and apply the proposed method to it. The experimental results demonstrate that the proposed method successfully detects the anomalous power behavior of an anomalous application program, while the existing method cannot.},
|
||||||
|
urldate = {2024-11-07},
|
||||||
|
booktitle = {2021 {IEEE} 27th {International} {Symposium} on {On}-{Line} {Testing} and {Robust} {System} {Design} ({IOLTS})},
|
||||||
|
author = {Takasaki, Kazunari and Kida, Ryoichi and Togawa, Nozomu},
|
||||||
|
month = jun,
|
||||||
|
year = {2021},
|
||||||
|
note = {ISSN: 1942-9401},
|
||||||
|
keywords = {anomalous behavior, Hardware, Internet of Things, IoT device, LSTM, Operating systems, power analysis, Security, Software, Steady-state, System analysis and design},
|
||||||
|
pages = {1--7},
|
||||||
|
annote = {This paper gets dangerously close. If I understand correctly, they do not use the data from the machine. They use previous power consumption data to predict the next power data. Because the power consumption should follow a steady pattern for the same program, then deviation can be detected. Read the full article to be sure.
|
||||||
|
},
|
||||||
|
file = {Full Text PDF:/home/grizzly/Zotero/storage/HQBNCHA9/Takasaki et al. - 2021 - An Anomalous Behavior Detection Method Based on Power Analysis Utilizing Steady State Power Waveform.pdf:application/pdf;IEEE Xplore Abstract Record:/home/grizzly/Zotero/storage/7ECVKIEA/9486706.html:text/html},
|
||||||
|
}
|
||||||
|
|
||||||
|
@inproceedings{moreno_efficient_2016,
|
||||||
|
title = {Efficient program tracing and monitoring through power consumption - with a little help from the compiler},
|
||||||
|
url = {https://ieeexplore.ieee.org/document/7459561?arnumber=7459561},
|
||||||
|
abstract = {Ensuring correctness and enforcing security are growing concerns given the complexity of modern connected devices and safety-critical systems. A promising approach is non-intrusive runtime monitoring through reconstruction of program execution traces from power consumption measurements. This can be used for verification, validation, debugging, and security purposes. In this paper, we propose a framework for increasing the effectiveness of power-based program tracing techniques. These systems determine the most likely block of source code that produced an observed power trace (CPU power consumption as a function of time). Our framework maximizes distinguishability between power traces for different code blocks. To this end, we provide a special compiler optimization stage that reorders intermediate representation (IR) and determines the reorderings that lead to power traces with highest distances between each other, thus reducing the probability of misclassification. Our work includes an experimental evaluation, using LLVM for an ARM architecture. Experimental results confirm the effectiveness of our technique.},
|
||||||
|
urldate = {2024-11-07},
|
||||||
|
booktitle = {2016 {Design}, {Automation} \& {Test} in {Europe} {Conference} \& {Exhibition} ({DATE})},
|
||||||
|
author = {Moreno, Carlos and Kauffman, Sean and Fischmeister, Sebastian},
|
||||||
|
month = mar,
|
||||||
|
year = {2016},
|
||||||
|
note = {ISSN: 1558-1101},
|
||||||
|
keywords = {Power demand, Power measurement, Security, Electronic mail, Monitoring, Optimization, Training},
|
||||||
|
pages = {1556--1561},
|
||||||
|
annote = {The power consumption is correlated with the activity of the program for “verification, validation, debugging, and security purposes”. It does require the compiler order code blocks for maximal detectability.
|
||||||
|
},
|
||||||
|
file = {Full Text PDF:/home/grizzly/Zotero/storage/J7YXVQBD/Moreno et al. - 2016 - Efficient program tracing and monitoring through power consumption - with a little help from the com.pdf:application/pdf;IEEE Xplore Abstract Record:/home/grizzly/Zotero/storage/9YQB5S9Y/7459561.html:text/html},
|
||||||
|
}
|
||||||
|
|
||||||
|
@inproceedings{zhu_towards_2012,
|
||||||
|
title = {Towards a {Novel} {Approach} for {Hidden} {Process} {Detection} {Based} on {Physical} {Memory} {Scanning}},
|
||||||
|
url = {https://ieeexplore.ieee.org/document/6405787/?arnumber=6405787},
|
||||||
|
doi = {10.1109/MINES.2012.239},
|
||||||
|
abstract = {Leveraging developed root kit, malware could deeply hide its own process and hardly be detected. Based on analyzing various existing detecting technologies, a novel approach for hidden process detection was proposed in this paper. The approach used page table entry patching to traverse physical memory and obtain the raw data, and formulated the characteristic selection constraints to extract reliable process object characteristics, which were used to search process object instances based on string matching in physical memory to form a credible list of processes. The approach could also be used to search other kernel objects on varieties of system platforms. The experimental results show that new detection is effective in hidden process searching.},
|
||||||
|
urldate = {2024-11-06},
|
||||||
|
booktitle = {2012 {Fourth} {International} {Conference} on {Multimedia} {Information} {Networking} and {Security}},
|
||||||
|
author = {Zhu, Junhu and Zhou, Tianyang and Wang, Qingxian},
|
||||||
|
month = nov,
|
||||||
|
year = {2012},
|
||||||
|
note = {ISSN: 2162-8998},
|
||||||
|
keywords = {Hardware, Security, Data structures, hidden process, Kernel, Memory management, paging mechanism, physical memory scan, Process control, string matching},
|
||||||
|
pages = {662--665},
|
||||||
|
annote = {Yet another memory analysis tool to detect hidden processes. This time they use “physical memory scan” but it is just another version of memory analysis that is host-based.
|
||||||
|
},
|
||||||
|
file = {Full Text PDF:/home/grizzly/Zotero/storage/64LW8E8I/Zhu et al. - 2012 - Towards a Novel Approach for Hidden Process Detection Based on Physical Memory Scanning.pdf:application/pdf;IEEE Xplore Abstract Record:/home/grizzly/Zotero/storage/P5444QL5/6405787.html:text/html},
|
||||||
|
}
|
||||||
|
|
||||||
|
@article{nasereddin_new_2024,
|
||||||
|
title = {A new approach for detecting process injection attacks using memory analysis},
|
||||||
|
volume = {23},
|
||||||
|
issn = {1615-5270},
|
||||||
|
url = {https://doi.org/10.1007/s10207-024-00836-w},
|
||||||
|
doi = {10.1007/s10207-024-00836-w},
|
||||||
|
abstract = {This paper introduces a new approach for examining and analyzing fileless malware artifacts in computer memory. The proposed approach offers the distinct advantage of conducting a comprehensive live analysis of memory without the need for periodic memory dumping. Once a new process arrives, log files are collected by monitoring the Event Tracing for Windows facility as well as listing the executables of the active process for violation detection. The proposed approach significantly reduces detection time and minimizes resource consumption by adopting parallel computing (programming), where the main software (Master) divides the work, organizes the process of searching for artifacts, and distributes tasks to several agents. A dataset of 17411 malware samples is used in the assessment of the new approach. It provided satisfactory and reliable results in dealing with at least six different process injection techniques including classic DLL injection, reflective DLL injection, process hollowing, hook injection, registry modifications, and .NET DLL injection. The detection accuracy rate has reached \$\$99.93{\textbackslash}\%\$\$with a false-positive rate of \$\$0.068{\textbackslash}\%\$\$. Moreover, the accuracy was monitored in the case of launching several malwares using different process injection techniques simultaneously, and the detector was able to detect them efficiently. Also, it achieved a detection time with an average of 0.052 msec per detected malware.},
|
||||||
|
language = {en},
|
||||||
|
number = {3},
|
||||||
|
urldate = {2024-11-06},
|
||||||
|
journal = {International Journal of Information Security},
|
||||||
|
author = {Nasereddin, Mohammed and Al-Qassas, Raad},
|
||||||
|
month = jun,
|
||||||
|
year = {2024},
|
||||||
|
keywords = {Fileless malware, Intrusion detection, Malware analysis and detection, Memory forensics, Process injection attacks},
|
||||||
|
pages = {2099--2121},
|
||||||
|
annote = {Again an idea based on memory analysis.
|
||||||
|
One good point is the use of known malware.
|
||||||
|
},
|
||||||
|
file = {Full Text PDF:/home/grizzly/Zotero/storage/63B57ANI/Nasereddin and Al-Qassas - 2024 - A new approach for detecting process injection attacks using memory analysis.pdf:application/pdf},
|
||||||
|
}
|
||||||
|
|
||||||
|
@inproceedings{wang_procguard_2022,
|
||||||
|
title = {{ProcGuard}: {Process} {Injection} {Behaviours} {Detection} {Using} {Fine}-grained {Analysis} of {API} {Call} {Chain} with {Deep} {Learning}},
|
||||||
|
shorttitle = {{ProcGuard}},
|
||||||
|
url = {https://ieeexplore.ieee.org/document/10063560/?arnumber=10063560},
|
||||||
|
doi = {10.1109/TrustCom56396.2022.00109},
|
||||||
|
abstract = {New malware increasingly adopts novel fileless techniques to evade detection from antivirus programs. Process injection is one of the most popular fileless attack techniques. This technique makes malware more stealthy by writing malicious code into memory space and reusing the name and port of the host process. It is difficult for traditional security software to detect and intercept process injections due to the stealthiness of its behavior. We propose a novel framework called ProcGuard for detecting process injection behaviors. This framework collects sensitive function call information of typical process injection. Then we perform a fine-grained analysis of process injection behavior based on the function call chain characteristics of the program, and we also use the improved RCNN network to enhance API analysis on the tampered memory segments. We combine API analysis with deep learning to determine whether a process injection attack has been executed. We collect a large number of malicious samples with process injection behavior and construct a dataset for evaluating the effectiveness of ProcGuard. The experimental results demonstrate that it achieves an accuracy of 81.58\% with a lower false-positive rate compared to other systems. In addition, we also evaluate the detection time and runtime performance loss metrics of ProcGuard, both of which are improved compared to previous detection tools.},
|
||||||
|
urldate = {2024-11-06},
|
||||||
|
booktitle = {2022 {IEEE} {International} {Conference} on {Trust}, {Security} and {Privacy} in {Computing} and {Communications} ({TrustCom})},
|
||||||
|
author = {Wang, Juan and Ma, Chenjun and Li, Ziang and Yuan, Huanyu and Wang, Jie},
|
||||||
|
month = dec,
|
||||||
|
year = {2022},
|
||||||
|
note = {ISSN: 2324-9013},
|
||||||
|
keywords = {Malware, API call chain, deep learning, Deep learning, Heuristic algorithms, Measurement, Privacy, process injection, Runtime, Writing},
|
||||||
|
pages = {778--785},
|
||||||
|
annote = {In this paper, the ressource monitored to detect hidden processes is specific API calls that are related to code injection. This method seems more specific to a certain type of masquerading.
|
||||||
|
},
|
||||||
|
file = {Full Text PDF:/home/grizzly/Zotero/storage/9KU2EXSB/Wang et al. - 2022 - ProcGuard Process Injection Behaviours Detection Using Fine-grained Analysis of API Call Chain with.pdf:application/pdf;IEEE Xplore Abstract Record:/home/grizzly/Zotero/storage/WCSP8PKH/10063560.html:text/html},
|
||||||
|
}
|
||||||
|
|
||||||
|
@inproceedings{vaas_detecting_2017,
|
||||||
|
title = {Detecting disguised processes using application-behavior profiling},
|
||||||
|
url = {https://ieeexplore.ieee.org/document/7943508},
|
||||||
|
doi = {10.1109/THS.2017.7943508},
|
||||||
|
abstract = {In order to avoid detection, malware can disguise itself as a legitimate program or hijack system processes to reach its goals. Commonly used signature-based Intrusion Detection Systems (IDS) struggle to distinguish between these processes and are thus only of limited use to detect such attacks. They also have the shortcoming that they need to be updated frequently to possess the latest malware definitions. This makes them inherently prone to missing novel attack techniques. Misuse detection IDSs however overcome this problem by maintaining a ground truth of normal application behavior while reporting deviations as anomalies. In our approach, we try to accomplish this by observing a process' memory consumption. This is for two reasons: We expect the readings to be less volatile in comparison to for instance network operations. Second, by breaking the problem down, we are able to investigate thoroughly while still laying the foundations for future expansion. We use the observations from a given host to train a machine learning algorithm. After an initial learning phase, we evaluate the model with readings from the application it has been trained on and other applications in order to assess its quality. Our results indicate that the efficacy of this method is highly dependent on parametrizing the machine learning algorithm appropriately. A large variance in accuracy with only slightly altered inputs confirms this suggestion. We finish with a discussion on deploying such an IDS at scale in a realistic scenario.},
|
||||||
|
urldate = {2024-11-01},
|
||||||
|
booktitle = {2017 {IEEE} {International} {Symposium} on {Technologies} for {Homeland} {Security} ({HST})},
|
||||||
|
author = {Vaas, Christian and Happa, Jassim},
|
||||||
|
month = apr,
|
||||||
|
year = {2017},
|
||||||
|
keywords = {Malware, Training, Memory management, Intrusion detection, Data models, Time series analysis},
|
||||||
|
pages = {1--6},
|
||||||
|
annote = {This paper uses a similar idea as I do. They collect digital footprint (instead of physical ones for me) to assess the legitimacy of a process. They use memory usage as their second source of truth.
|
||||||
|
They evaluate their method on 1 day of machine data and the legitimacy of a few processes: explorer, texmaker, mintty and ssh.
|
||||||
|
|
||||||
|
Differences: Their method is host-based. So it is not immune to attackers. It simply takes the attacker one more step to bypass or feed erroneous data to the IDS.
|
||||||
|
|
||||||
|
},
|
||||||
|
file = {IEEE Xplore Abstract Record:/home/grizzly/Zotero/storage/RJHM6UXV/7943508.html:text/html;PDF:/home/grizzly/Zotero/storage/4J5RMGK9/Vaas and Happa - 2017 - Detecting disguised processes using application-behavior profiling.pdf:application/pdf},
|
||||||
|
}
|
||||||
|
|
||||||
|
@inproceedings{yu-tao_hpdbf_2016,
|
||||||
|
title = {{HPDBF}: {A} forensics method for hidden process based on memory analysis},
|
||||||
|
shorttitle = {{HPDBF}},
|
||||||
|
url = {https://ieeexplore.ieee.org/document/8070249/?arnumber=8070249},
|
||||||
|
doi = {10.1109/ICCSNT.2016.8070249},
|
||||||
|
abstract = {Malicious processes usually cooperate with concealing technology to hide themselves. The detection against hidden processes can effectively narrow the range of malicious processes. Behavior analysis is then implemented on the filtered process to finally locate the malicious one. In this paper, a method of hidden process detection and behavior forensics based on memory analysis is proposed. It uses virtual machine monitor to extract and analyze memory data, detecting hidden processes; then analyzes the executable code of the target process to determine whether there is malicious behavior during the operation of the process. Experimental results demonstrated the effectiveness and the acceptable performance overhead of the proposed method.},
|
||||||
|
urldate = {2024-11-06},
|
||||||
|
booktitle = {2016 5th {International} {Conference} on {Computer} {Science} and {Network} {Technology} ({ICCSNT})},
|
||||||
|
author = {Yu-Tao, Zhao and Qing-Bao, Li and Guang-Yu, Zeng and San-Jun, Cheng},
|
||||||
|
month = dec,
|
||||||
|
year = {2016},
|
||||||
|
keywords = {hidden process, Kernel, behavior forensics, Forensics, Linux, memory analysis, Schedules, semantic reconstruction, Semantics, Virtual machine monitors},
|
||||||
|
pages = {705--710},
|
||||||
|
annote = {Same idea as Vaas and Happa, use memory analysis to detect hidden processes.
|
||||||
|
},
|
||||||
|
file = {Full Text PDF:/home/grizzly/Zotero/storage/FU379NT5/Yu-Tao et al. - 2016 - HPDBF A forensics method for hidden process based on memory analysis.pdf:application/pdf;IEEE Xplore Abstract Record:/home/grizzly/Zotero/storage/LNAZ34XB/8070249.html:text/html},
|
||||||
|
}
|
||||||
|
|
||||||
|
@misc{noauthor_unveiling_nodate,
|
||||||
|
title = {Unveiling {WolfsBane}: {Gelsemium}’s {Linux} counterpart to {Gelsevirine}},
|
||||||
|
shorttitle = {Unveiling {WolfsBane}},
|
||||||
|
url = {https://www.welivesecurity.com/en/eset-research/unveiling-wolfsbane-gelsemiums-linux-counterpart-to-gelsevirine/},
|
||||||
|
abstract = {ESET researchers analyzed previously unknown Linux backdoors that are connected to known Windows malware used by the China-aligned Gelsemium group, as well as to Project Wood.},
|
||||||
|
language = {en},
|
||||||
|
urldate = {2024-11-22},
|
||||||
|
file = {Snapshot:/home/grizzly/Zotero/storage/6WSUP3XC/unveiling-wolfsbane-gelsemiums-linux-counterpart-to-gelsevirine.html:text/html},
|
||||||
|
}
|
||||||
|
|
||||||
|
@misc{noauthor_unix-thrustbeurk_2024,
|
||||||
|
title = {unix-thrust/beurk},
|
||||||
|
copyright = {GPL-3.0},
|
||||||
|
url = {https://github.com/unix-thrust/beurk},
|
||||||
|
abstract = {BEURK Experimental Unix RootKit},
|
||||||
|
urldate = {2024-11-22},
|
||||||
|
publisher = {unix-thrust},
|
||||||
|
month = nov,
|
||||||
|
year = {2024},
|
||||||
|
note = {original-date: 2015-04-14T15:30:44Z},
|
||||||
|
}
|
||||||
1244
procver/ACNS/llncs.cls
Normal file
1244
procver/ACNS/llncs.cls
Normal file
File diff suppressed because it is too large
Load diff
129
procver/ACNS/main.tex
Normal file
129
procver/ACNS/main.tex
Normal file
|
|
@ -0,0 +1,129 @@
|
||||||
|
\documentclass[runningheads]{llncs}
|
||||||
|
%
|
||||||
|
\usepackage[T1]{fontenc}
|
||||||
|
% T1 fonts will be used to generate the final print and online PDFs,
|
||||||
|
% so please use T1 fonts in your manuscript whenever possible.
|
||||||
|
% Other font encondings may result in incorrect characters.
|
||||||
|
%
|
||||||
|
\usepackage{graphicx}
|
||||||
|
\usepackage{xcolor}
|
||||||
|
\usepackage{amsfonts}
|
||||||
|
\usepackage{amssymb}
|
||||||
|
% Used for displaying a sample figure. If possible, figure files should
|
||||||
|
% be included in EPS format.
|
||||||
|
|
||||||
|
\newcommand\agd[1]{{\color{red}$\bigstar$}\footnote{agd: #1}}
|
||||||
|
|
||||||
|
% If you use the hyperref package, please uncomment the following two lines
|
||||||
|
% to display URLs in blue roman font according to Springer's eBook style:
|
||||||
|
%\usepackage{color}
|
||||||
|
%\renewcommand\UrlFont{\color{blue}\rmfamily}
|
||||||
|
%\urlstyle{rm}
|
||||||
|
%
|
||||||
|
\begin{document}
|
||||||
|
%
|
||||||
|
\title{PowPrint: Big Patounes all over the Power Trace}
|
||||||
|
%
|
||||||
|
%\titlerunning{Abbreviated paper title}
|
||||||
|
% If the paper title is too long for the running head, you can set
|
||||||
|
% an abbreviated paper title here
|
||||||
|
%
|
||||||
|
\author{Arthur Grisel-Davy\inst{1}\orcidID{0000-1111-2222-3333} \and
|
||||||
|
Sebastiean Fischmeister\inst{1}\orcidID{1111-2222-3333-4444}}
|
||||||
|
%
|
||||||
|
\authorrunning{A. Grisel-Davy and Sebastian Fischmeister.}
|
||||||
|
% First names are abbreviated in the running head.
|
||||||
|
% If there are more than two authors, 'et al.' is used.
|
||||||
|
%
|
||||||
|
\institute{University of Waterloo, Waterloo, CA
|
||||||
|
\email{agriseld@uwaterloo.ca}\\
|
||||||
|
}
|
||||||
|
%
|
||||||
|
\maketitle % typeset the header of the contribution
|
||||||
|
%
|
||||||
|
\begin{abstract}
|
||||||
|
The cat and mouse game has led attackers to use ever-increasingly complex evasion technics to hide their malware.
|
||||||
|
|
||||||
|
\keywords{Intrusion Detection \and Side-Channel Analysis \and Power Trace.}
|
||||||
|
\end{abstract}
|
||||||
|
|
||||||
|
\section{Introduction}
|
||||||
|
%The modern landscape of malware families is diverse.
|
||||||
|
%Attackers write malware for a wide range or purposes, each with their goals, target systems, attacks vectors, and constraints.
|
||||||
|
%Some malware are purely destructive, designed to destroy data or equipement or harm people.
|
||||||
|
%Others have ulterior notive like disrupting target operations, extract sensitive information, or request ransoms.
|
||||||
|
%
|
||||||
|
%Most malware a complexe pieces of sotware that require expertise and time to developp.
|
||||||
|
%Among them, one group sits above all in terms of complexity and capabilities, the Advanced Persistent Threats.
|
||||||
|
%APTs are meta-malware that may not be directly intended to cause harm to the target.
|
||||||
|
%Instead, they are a framework from which a payloads can operate.
|
||||||
|
%The APT are diverse depending on the authors, the capabilities, and the intendent audience.
|
||||||
|
%However common capabilities of APTs are deployment, persistence, and stealth.
|
||||||
|
%
|
||||||
|
%In this sutdy, we are interested in the stealth capabilities of malwares.
|
||||||
|
%Malware authors often wish for their program to remain undetected on the infected machine.
|
||||||
|
%Hidden on the target, the malware can remain active and either continuously perform its intended actions or wait for commands.
|
||||||
|
%Effectively hiding a piece of software is a complex task on two main levels.
|
||||||
|
%First, from a filesystem of static analysispoint of view, the executable or code that consitute the malware must be invisible or appear innofensive.
|
||||||
|
%Then, when running, the malware must also either hide its activity from HIDS or masquerade a valid process.
|
||||||
|
%
|
||||||
|
%In this study, we consider the second case when a program is performing actions shile remaining invisible or innofensive from the operating system.
|
||||||
|
|
||||||
|
Malware developement has always been a field of computer science that rivals in complexity with the most current academic research.
|
||||||
|
To remain effective, malware must keep up and even lead the most advanced detection and prevention mechanisms.
|
||||||
|
This complexity has kept modern malware capable of infiltrate and iscrupt systems while avoiding detection.
|
||||||
|
|
||||||
|
While stealth may not be main focus of all malwares --- some are designed with destructive power or speed of deployement and action ---, the ability to remain hidden on the infected system --- called evasion --- is a common feature of many modern malware.
|
||||||
|
Thanks to the creativity of malware authors, many evasions technics have been used over time.
|
||||||
|
While most were discovered and documented, it is safe to assume that there are and will always be evasions technics that are on step ahead and bypases the current detection methods.
|
||||||
|
|
||||||
|
Evasions technics is un umbrella terms that englobes \agd{find appropriate word} multiple sub categories, each for a different purpose.
|
||||||
|
One aspect of evasion is the ability to conceal the malicious nature of the files that consitute the ;alware.
|
||||||
|
For this purpose, alware may employ homomorphic or metamorphic methods to "dejouer" signature analysis or use a fileless design to avoid analsysi altogether.
|
||||||
|
Another compleing capability is the ... \agd{find another evasion technic}
|
||||||
|
|
||||||
|
This study focuses on another specific evasion domain, process hiding.
|
||||||
|
The list of running processes is an obvious compeling ressource to start detectin malware.
|
||||||
|
To detect running malware, one could simply gather the list of all running software and search for known malware.
|
||||||
|
With the list of processes frequently collected, an HIDS \agd{replace acronym} can detect known malware, mine rules, define an activity profile, or detect anomalous situations \agd{}.
|
||||||
|
|
||||||
|
Staying off the process list is good first step for any malware aiming for stealth.
|
||||||
|
We can categorize the technics achieving this type of evasion between hiding and masquerading.
|
||||||
|
For process hiding, the goal is to execute a program and leave no trace of it in the process list.
|
||||||
|
For process masquerading, the aim is not so much to avoid the listing but to avoid the malware being listed with its real identity.
|
||||||
|
A process masquerading an another will assume its process name and characteristics, with the goal of appearing legitimate on the machine.
|
||||||
|
Process hiding and masquerading differ in their ultimate goal but leverage a lot of the same technics.
|
||||||
|
The core idea of process list manipulation is tampering with the process listing mechanism provided by the OS to the monitoring software.
|
||||||
|
Independently of the OS, attackers often rely on intercepting system's call to remove or replace information or directly manipulating kernel objects.
|
||||||
|
For the purpose of this study, we do not differentiate between Unix-based OSs and Windows systems as process hiding is a common practice for malware in both environments.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
\subsection{Contribution}
|
||||||
|
This paper proposes a novel approach for detecting tampering on the process listing.
|
||||||
|
|
||||||
|
|
||||||
|
\section{Related Work}
|
||||||
|
|
||||||
|
\section{Problem Statement}
|
||||||
|
|
||||||
|
\subsection{Attacker Model}
|
||||||
|
|
||||||
|
\section{Proposed Approach}
|
||||||
|
|
||||||
|
\section{Case Studies}
|
||||||
|
|
||||||
|
\section{Discussion}
|
||||||
|
|
||||||
|
\section{Conclusion}
|
||||||
|
|
||||||
|
\bibliography{biblio} % Import the bibliography
|
||||||
|
\bibliographystyle{plain} % set the reference style
|
||||||
|
|
||||||
|
\end{document}
|
||||||
28
procver/ACNS/notes.txt
Normal file
28
procver/ACNS/notes.txt
Normal file
|
|
@ -0,0 +1,28 @@
|
||||||
|
Main Points for the Introduction
|
||||||
|
|
||||||
|
Background and Motivation:
|
||||||
|
The increasing sophistication of malware and attack techniques, such as rootkits and masquerading processes, poses significant challenges to traditional detection mechanisms.
|
||||||
|
Hidden or masqueraded processes can evade standard tools by leveraging techniques like kernel-level manipulation, API hooking, or process injection.
|
||||||
|
|
||||||
|
Limitations of Current Approaches:
|
||||||
|
Signature-based and behavior-based detection methods are often circumvented by polymorphic or fileless malware.
|
||||||
|
Existing tools may struggle to differentiate between legitimate and malicious processes, especially when attackers mimic trusted processes.
|
||||||
|
|
||||||
|
Emerging Focus on Side-Channel Analysis:
|
||||||
|
Side-channel data, such as power consumption, has emerged as a promising non-invasive means of system monitoring.
|
||||||
|
Power consumption patterns inherently reflect the activity of running processes, including their computational and memory usage characteristics.
|
||||||
|
|
||||||
|
Research Gap:
|
||||||
|
While side-channel data has been explored for other applications, its potential for detecting hidden or masqueraded processes remains underexplored.
|
||||||
|
A reliable method to associate anomalous power consumption patterns with malicious process activity could significantly enhance detection capabilities.
|
||||||
|
|
||||||
|
Proposed Contribution:
|
||||||
|
Introduction of a novel method leveraging power consumption patterns to detect hidden or masqueraded processes.
|
||||||
|
Description of how the method identifies deviations from expected power usage profiles using advanced statistical or machine learning techniques.
|
||||||
|
|
||||||
|
Significance of the Work:
|
||||||
|
The proposed method offers a complementary tool to traditional detection systems, enhancing system security.
|
||||||
|
Its ability to utilize hardware-level data reduces reliance on potentially compromised software-based mechanisms.
|
||||||
|
|
||||||
|
Structure of the Article:
|
||||||
|
Overview of the proposed method, followed by an in-depth explanation of the methodology, experimental setup, results, and discussion on implications and limitations.
|
||||||
1548
procver/ACNS/splncs04.bst
Normal file
1548
procver/ACNS/splncs04.bst
Normal file
File diff suppressed because it is too large
Load diff
Loading…
Add table
Add a link
Reference in a new issue