www.inversecos.com Open in urlscan Pro
2a00:1450:4001:811::2013  Public Scan

Submitted URL: https://t.co/2qmGLm5c56
Effective URL: https://www.inversecos.com/2022/06/detecting-linux-anti-forensics-log.html
Submission: On August 07 via manual from US — Scanned from DE

Form analysis 1 forms found in the DOM

https://www.inversecos.com/search

<form action="https://www.inversecos.com/search" target="_top">
  <div class="search-input">
    <input aria-label="Search this blog" autocomplete="off" name="q" placeholder="Search this blog" value="">
  </div>
  <input class="search-action flat-button" type="submit" value="Search">
</form>

Text Content

Skip to main content


INVERSECOS






DETECTING LINUX ANTI-FORENSICS LOG TAMPERING

 * Get link
 * Facebook
 * Twitter
 * Pinterest
 * Email
 * Other Apps

June 22, 2022

 






When forensically examining Linux systems for malicious intrusion, responders
often rely on the following three artefacts to determine logins and logouts:



 * /var/run/utmp – currently logged in users
 * /var/run/wtmp – current, past logins and system reboot 
 * /var/log/btmp – bad login attempts 



Of course, these artefacts are not all you can forensically investigate for
malicious access (there are other artefacts you can examine), however, these
will be the focus of this anti-forensics blog post. 



In this post, I will walk through two methods of removing and tampering with
these aretfacts to delete the malicious logins you want to hide. The first
method removes the log line completely from the file through overwriting the
binary file, the second method focuses on altering the hex of the file but is
more obvious to detect. I will then walk through a simple way of detecting both
methods based on timestamps that you can check. If timestamps are king – then
I’ll be his queen!





Method 1 – Nulling the Entry 

This method is almost trivial to perform but leaves at least two methods of
detection for a responder. The picture below shows the untampered output of the
/var/log/wtmp binary. Please note that I will be using this file for the
examples, but this technique can be used across all 3 artefacts. 




To kick this off, the attacker should ensure no bash history is being logged.
You can do this through running the command below to set the HISTSIZE=0. This
will prevent the shell commands from being logged when you’re on the system: 





There are attack tools you can use to do this – but why would you load
unnecessary attack tools on the system when you can just LoL? Open up the
hexeditor on /var/log/wtmp. I am using “hexedit”. 


The account I want to remove from the log is “shutdown” (why? because I felt
like it and there is no attacker on my sift workstation lol). The starting point
to edit is where you note the first “~” in hex. I have highlighted the areas to
edit in purple. Edit these so it is all “0” by nulling all the values out. 
If you mess this part up you will end up clearing the entire file xD. 





The screenshot below shows the output of /var/log/wtmp now. You can see this
entry has been removed as it’s been nulled out. The date has also reverted to
the default date. 







Method 2 – Overwriting the file


If bash_history is turned off this is slightly harder to detect as this
technique results in the entire lines being omitted from the log as we are
complexly overwriting the /var/log/wtmp file. The detection of this can be done
by looking at timestamps though! UwU


We can accomplish this in two steps. The first is to grep out the lines we want
to remove into a “clean” file. In the screenshot below, you can see I got rid of
the “sansforensics” login.





Then we want to replace the contents of /var/log/wtmp with the cleaned file:





If you view the results, you can see the entries for “sansforensics” are
completely gone: 





DETECTION METHODOLOGY
This first method of anti-forensics / log evasion is trivial to detect and the
detection is pretty high-fidelity. I would look for entries in wtmp, btmp and
utmp where:
 * Values are zeroes (null) as this is not normal at all 
 * Detect entries with the datetime stomped to “1970*”

The next step is to review the timestamp of the actual /var/log/wtmp file. This
file should always have the timestamp of the LAST entry that exists within the
file. Please observe this following example of a non-tampered wtmp file:




And now compare it to the timestamps on the wtmp file. You will see they are
always supposed to match:





Following this logic, if you review the timestamps for wtmp post tampering – the
timestamps now do not match up ;)






Therefore, to summarise the key steps in detecting this:
 * Bash history (if HISTSIZE isn’t 0)
 * Values of zero (null) in wtmp, btmp, utmp
 * Entries with a timestamp containing the year 1970 (default time)
 * Timestamp mismatch between the last entry and the file timestamp of the file 

Happy hunting! X 






detecting linux defence evasion linux anti-forensics linux defence evasion linux
log tampering

 * Get link
 * Facebook
 * Twitter
 * Pinterest
 * Email
 * Other Apps


COMMENTS



POST A COMMENT




POPULAR POSTS FROM THIS BLOG


OFFICE365 ATTACKS: BYPASSING MFA, ACHIEVING PERSISTENCE AND MORE - PART I

September 16, 2021
APTs are actively attacking Office 365 (O365) – finding mechanisms to bypass MFA
and to impersonate users regardless of whether you reset their passwords. When I
was looking through the Mitre mapping of O365 attacks , I noticed that it didn’t
include many methods of intrusion and actions on objectives that can occur with
O365. In conversations with several clients, I couldn’t help but notice that
there’s still a heavy focus on “endpoint” style attacks and not much resource /
thought put into attacks that can occur in the cloud. Attacking O365 gives an
attacker many benefits… it allows an attacker to impersonate users, alter MFA
settings, register malicious devices, access Teams messages, download sensitive
emails, access SharePoint, OneDrive, register malicious applications and various
other actions that could allow them to maintain persistence in your environment.
This blog post explores the various ways O365 can be attacked. I will be writing
a Part II follow up that describes the me
Read more


FORENSIC ANALYSIS OF ANYDESK LOGS

February 10, 2021
Most threat actors during ransomware incidents utilise some type of remote
access tools - one of them being AnyDesk. This is a free remote access tool that
threat actors download onto hosts to access them easily and also for
bidirectional file transfer.  There are two locations for where AnyDesk logs are
stored on the Windows file system: %programdata%\AnyDesk\ad_svc.trace
%appdata%\Anydesk\ad.trace The AnyDesk logs can be found under the appdata
located within each users' directory where the tool has been installed. Forensic
analysis of these logs reveal interesting pieces of information inside the
"ad.trace" log: Remote IP where the actor connected from File transfer activity
Locating the Remote IP Connecting to AnyDesk Inside the "ad.trace" log you can
grep for the following term "External address" and this should reveal the
following line pasted below. I have redacted the IP for privacy's sake: info
2021-02-04 23:25:10.500       lsvc   9988  
Read more


BACKDOOR OFFICE 365 AND ACTIVE DIRECTORY - GOLDEN SAML

September 02, 2021
Backdoors can bypass all MFA requirements put in place by an organisation.
Earlier this year, I worked an engagement with an APT group that had a keen
interest on the client’s Office 365 environment, where this group found a way to
bypass authentication controls to access the environment. Given that most
clients either have a hybrid authentication model set-up or are fully in the
cloud – I think it’s important that most blue teams / defenders / hunters are
aware of the various techniques threat actors are using against Azure AD.
Compromise of the AD FS server token-signing certificate could result in access
to the Azure/Office365 environment by the attacker. By default, this certificate
is valid for a year and will allow an attacker to log into Azure/Office365 as
any user within AD regardless of any password resets and MFA. The implication of
this, is that the attacker maintains persistence and has a means to re-enter
into the environment, escaping detection. This blog post will cover
Read more
Powered by Blogger


REPORT ABUSE


MY BOOK

 * How to get a job in cybersecurity earning over six figures : Zero to Cyber
   Hero

inversecos Visit profile


LINA LAU

I'm a lead incident responder and security researcher.

If you'd like to get in touch with me, hit me up on twitter @inversecos


SOCIAL

 * Twitter
 * YouTube
 * LinkedIn
 * Tiktok


SEARCH




BLOG ARCHIVE

 * August 20221
 * July 20222
 * June 20223
 * May 20222
 * April 20222
 * March 20221
 * January 20221
 * December 20211
 * November 20211
 * October 20213

 * September 20212
 * May 20211
 * February 20211
 * April 20201
 * November 20191
 * March 20181
 * October 20172
 * June 20172

Show more Show less
Diese Website verwendet Cookies von Google, um Dienste anzubieten und Zugriffe
zu analysieren. Deine IP-Adresse und dein User-Agent werden zusammen mit
Messwerten zur Leistung und Sicherheit für Google freigegeben. So können
Nutzungsstatistiken generiert, Missbrauchsfälle erkannt und behoben und die
Qualität des Dienstes gewährleistet werden.Weitere InformationenOk